Do not assign undefined to window event handlers in IE/MSHTML
in [JavaScript]
|
Prev: using screenX and screenY?
Next: ECMA-262-5 in detail. Chapter 1. Properties and Property Descriptors.
From: Lasse Reichstein Nielsen on 30 Apr 2010 10:33 Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > Lasse Reichstein Nielsen wrote: > >> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: >>> Garrett Smith wrote: >>>> | The Function prototype object is itself a Function object (its >>>> | [[Class]] is "Function") that, when invoked, accepts any arguments and >>>> | returns undefined. >>> >>> Again, that does _not_ say what can happen between the moment the >>> function is called and the moment it returns. So it does _not_ support >>> your assumption that the function would be a "no-op" either way. >> >> Ofcourse it does. It says what the function does. Just like any other >> function specified in the standard, it's not allowed to do observable >> things that are not stated. > > So it could very well do things that are not observable by the caller. Well, duh. It can do anything that isn't observable - but how would you know? I'm pretty sure that an implementation will do a lot of things (like increment the program counter register), but that's not observable behavior at the language level. That's the idea of a specification like the ECMAScript standard: it specifies the observable behavior (the extrinsic semantics if you will) and an implementation is conformant if it has the same observable behavior, neither more nor less [1]. If it has the same observable behavior as a no-op function (which, if that concept makes any sense, would definitly include a function with an empty body), then it *is* a no-op function. So, by the specification, the observable behavior of Function.prototype is fully specified, and that behavior is that of a no-op function. >> You are reading something into this specification that isn't there, namely >> that this is some minimal requrirement of what the function must do, and >> not, like everywhere else, the exact specification. > > No and no. Are you not reading the specification such that a conformant implementation may have a Function.prototype that does something observable between entering the function and returning undefined? Otherwise what does "that does _not_ say what can happen between the moment the function is called and the moment it returns" mean? I say it does say. I cannot see how the String function is *more* definitive than Function.prototype. One says "Returns a String value ..." (with specification of how that string value is computed), the other says (accept all arguments) ".. and returns undefined". >> This specification is equivalent to using the "algorithm": >> 1. Return undefined > > I concur, but that is not at issue here. Then I fail to see what the issue is. Maybe you can elaborate what your point is? /L [1] Except where extensions are allowed, obviously. -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Thomas 'PointedEars' Lahn on 30 Apr 2010 11:24 Lasse Reichstein Nielsen wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: >> Lasse Reichstein Nielsen wrote: >>> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: >>>> Garrett Smith wrote: >>>>> | The Function prototype object is itself a Function object (its >>>>> | [[Class]] is "Function") that, when invoked, accepts any arguments >>>>> | [[and >>>>> | returns undefined. >>>> >>>> Again, that does _not_ say what can happen between the moment the >>>> function is called and the moment it returns. So it does _not_ support >>>> your assumption that the function would be a "no-op" either way. >>> >>> Ofcourse it does. It says what the function does. Just like any other >>> function specified in the standard, it's not allowed to do observable >>> things that are not stated. >> So it could very well do things that are not observable by the caller. > > Well, duh. It can do anything that isn't observable - but how would > you know? One could read the source code for some implementations. Otherwise, I do not know. Neither does Garrett. That is why it is a fallacy (of his) to assume the value of this property qualifies as a "no-op function" that is "safe everywhere". >>> You are reading something into this specification that isn't there, >>> namely that this is some minimal requrirement of what the function must >>> do, and not, like everywhere else, the exact specification. >> No and no. > > Are you not reading the specification such that a conformant > implementation may have a Function.prototype that does something > observable between entering the function and returning undefined? Mu. > Otherwise what does "that does _not_ say what can happen between the > moment the function is called and the moment it returns" mean? > I say it does say. Not sufficiently for this function to be assumed a "no-op". > I cannot see how the String function is *more* definitive than > Function.prototype. It specifies how the return value is to be computed to begin with. >>> This specification is equivalent to using the "algorithm": >>> 1. Return undefined >> I concur, but that is not at issue here. > > Then I fail to see what the issue is. > Maybe you can elaborate what your point is? A "no-op" (no-operation, from the assembly language mnemonic) does nothing at all. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Lasse Reichstein Nielsen on 30 Apr 2010 12:58 Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > A "no-op" (no-operation, from the assembly language mnemonic) does nothing > at all. But a function must return a value. That means that a "no-op function" is a contradiction in terms (if one uses your definition of no-op). I.e., saying "no-op function" is as meaningless as saying "square circle". I, however, didn't have any problem interpreting the intended meaning of "no-op function" in this context, e.g., something equivalent to function(){} and Function.prototype is such a function. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Thomas 'PointedEars' Lahn on 30 Apr 2010 15:22 Lasse Reichstein Nielsen wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: >> A "no-op" (no-operation, from the assembly language mnemonic) does >> nothing at all. > > But a function must return a value. That means that a "no-op function" > is a contradiction in terms (if one uses your definition of no-op). > I.e., saying "no-op function" is as meaningless as saying "square circle". > > I, however, didn't have any problem interpreting the intended meaning > of "no-op function" in this context, e.g., something equivalent to > function(){} > and Function.prototype is such a function. The initial value of the property is referring to such a Function object. However, the property value can be modified in conforming implementations of ECMAScript Edition 3 (but not in conforming implementations of Edition 5) without side effects to the normal operation of Function objects (as the initial value must be used there). Modification may be performed both by a conforming implementation or the user (for whatever reason). This puts into doubt the opinion that using Function.prototype for that purpose would be "safe everywhere", and that assigning the result of the evaluation of the expression function () {} as a really safe, clear and unambiguous value instead is not to be preferred. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Garrett Smith on 30 Apr 2010 15:33
Lasse Reichstein Nielsen wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > >> A "no-op" (no-operation, from the assembly language mnemonic) does nothing >> at all. > > But a function must return a value. That means that a "no-op function" > is a contradiction in terms (if one uses your definition of no-op). > I.e., saying "no-op function" is as meaningless as saying "square circle". > > I, however, didn't have any problem interpreting the intended meaning > of "no-op function" in this context, e.g., something equivalent to > function(){} > and Function.prototype is such a function. > It's as simple as that. Thanks, BTW. The discussion was wearing me out. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |