Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: John G Harris on 23 May 2010 06:52 On Thu, 20 May 2010 at 09:08:53, in comp.lang.javascript, Richard Cornford wrote: >On May 20, 4:18 pm, John G Harris wrote: >> On Wed, 19 May 2010 at 09:22:43, Richard Cornford wrote: >> >><snip>>while you can observe the >>> modification to an object and conclude that there must >>> be some 'referencing' mechanism that has all values that >>> are objects 'referring' to the single object >> >> <snip> >> >> Have you found the words in ECMA 262 that actually say >> that? If you have please tell me where as I haven't. It >> seems to be 'common knowledge' but not explicit. > >The words that actually say what exactly? There are no words in the >spec that say "can ... conclude", the ability to do that as a result >of the observation is evidently a fact (as at least one person has >done so). Yes, I didn't say it very clearly. I want to know which words in ECMA 262 say that you can get at the insides of the same object via two different variables. I've finally managed to plough through the many sections of the standard needed to find the answer. Suppose you execute these two statements : b = new Object(); c = b; and follow the formal ES3 definitions of what will happen. After tracing through all the gets, puts, returns, etc. you will find that the 'value' of b *is* the newly created object, and the 'value' of c is also that same object. Thus any change to the insides of the new object made via b is also visible via c. Obviously, the meaning of 'value' in ECMAScript is somewhat different to its meaning in other languages. If 'value' seems confusing then we can turn to the informal ES3 Overview section where properties are said to be containers. Each property, and so each variable, is said to contain either a primitive value or an object. Thus both b and c contain the same newly created object in the same way that both New York and North America contain Wall Street. Unlike real geography, an object can indirectly contain itself, making life difficult for the garbage collector. If you ask whether function arguments are passed by this or by that or by something else in ECMAScript the only correct answer is that all arguments are passed by containment. Any disagreement can only be about which feature of which other language it most closely resembles. The ES5 standard adds much complication to the formal definitions but appears to make no essential difference to these conclusions. John -- John Harris
From: Richard Cornford on 24 May 2010 06:58 On May 23, 11:52 am, John G Harris wrote: > On Thu, 20 May 2010 Richard Cornford wrote: >>On May 20, 4:18 pm, John G Harris wrote: >>> On Wed, 19 May 2010 at 09:22:43, Richard Cornford wrote: >>>> while you can observe the >>>> modification to an object and conclude that there must >>>> be some 'referencing' mechanism that has all values that >>>> are objects 'referring' to the single object >>> <snip> >>> Have you found the words in ECMA 262 that actually say >>> that? If you have please tell me where as I haven't. It >>> seems to be 'common knowledge' but not explicit. > >> The words that actually say what exactly? There are no >> words in the spec that say "can ... conclude", the ability >> to do that as a result of the observation is evidently a >> fact (as at least one person has done so). > > Yes, I didn't say it very clearly. I want to know which words > in ECMA 262 say that you can get at the insides of the same > object via two different variables. I've finally managed to > plough through the many sections of the standard needed to > find the answer. That will save me having to look up all the references in that spec. > Suppose you execute these two statements : > > b = new Object(); > c = b; > > and follow the formal ES3 definitions of what will happen. After > tracing through all the gets, puts, returns, etc. you will find > that the 'value' of b *is* the newly created object, and the >'value' of c is also that same object. Thus any change to the > insides of the new object made via b is also visible via c. > > Obviously, the meaning of 'value' in ECMAScript is somewhat > different to its meaning in other languages. Probably at least some other languages, maybe most (I don't want to think about that at the moment). We have a situation where a value can be an object; the object *is* a value. We can be pretty sure, from experience of how computers work, that an implementation is going to be achieving that by employing some sort of reference, but that isn't a concern of ECMAScript itself. ECMAScript stops at asserting that objects are values. > If 'value' seems confusing then we can turn to the informal ES3 > Overview section where properties are said to be containers. > Each property, and so each variable, is said to contain either > a primitive value or an object. Thus both b and c contain the > same newly created object in the same way that both New York > and North America contain Wall Street. Wouldn't you b and c example above be better paralleled with, say, Boston and New York both containing Wall Street? > Unlike real geography, I don't think geography is going to prove that useful in this case. > an object can indirectly contain itself, > making life difficult for the garbage collector. > > If you ask whether function arguments are passed by this or by > that or by something else in ECMAScript the only correct answer > is that all arguments are passed by containment. Are they? If we accept 'properties "contain" values (so may contain objects as objects are values)' then if the mechanics of passing arguments to function calls does not involve properties of objects (at any distinct step) then they will not be contained at that point, and may not be being "passed by containment". (I may propose that at the point of the having the result of the call to the internal GetValue function in the algorithm for evaluating an Arguments list (11.2.4 (3rd Ed.)) represents having only the value, without any 'container'.) Suppose we attempt to address this question form the other end, and instead of worrying about how an argument is passed to a function call instead look at how a function call receives its arguments. In ECMAScript terms a function call always 'receives its arguments as (ECMAScript) values'. This is guaranteed by the GetValue call in the Arguments list algorithm, and it is here that the implications for the possible 'passing on' of - this - values come from (there can be no Reference types received as arguments to function calls). > Any disagreement can only be about which feature of which > other language it most closely resembles. While that disagreement is evident I doubt that will prove the "only" subject of disagreement. > The ES5 standard adds much complication to the formal definitions > but appears to make no essential difference to these conclusions. That is my impression too. Richard.
From: Richard Cornford on 24 May 2010 07:02 On May 20, 6:37 pm, Tim Streater wrote: > Richard Cornford wrote: <snip> >> However, it has been pointed out that there are cases where the >> complier can observe variables, being assigned number values, and >> being employed in such a way as to, say, guarantee that a 32 bit >> signed integer could do the job (i.e. a loop counter starting at >> zero and counting up to some known value). > > You mean e.g. and not i.e. I may have meant e.g., if I could think of a single other example. Richard.
From: Lasse Reichstein Nielsen on 24 May 2010 12:22 Richard Cornford <Richard(a)litotes.demon.co.uk> writes: > I may have meant e.g., if I could think of a single other example. Other examples: The operands or result of any bitwise operation other than >>>, which needs a 32-bit unsigned integer for the result (but you can ignore that if it's used as operand of another bitwise operation). The return value of String.prototype.charCodeAt. (The problem is to recognize that that is the function being called). /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Richard Cornford on 24 May 2010 13:08
On May 24, 5:22 pm, Lasse Reichstein Nielsen wrote: > Richard Cornford writes: >> I may have meant e.g., if I could think of a single other >> example. > > Other examples: > > The operands or result of any bitwise operation other than > >>>, which needs a 32-bit unsigned integer for the result > (but you can ignore that if it's used as operand of another > bitwise operation). I assume you mean numeric literal operands. So if - x|0 - there is no need to create an IEEE double from the '0' as a 32 bit (or even smaller) integer will do? It is not nearly so easy to do that for the 'x'. > The return value of String.prototype.charCodeAt. (The problem > is to recognize that that is the function being called). When you do a math operation with that return value don't you need to be checking its type in order not to handle it as an IEEE double precision floating point number? Then, isn't there an implied overhead of extra type checking for all math operations? Richard. |