Thq Quiz
in [JavaScript]
|
Prev: FAQ Topic - How do I close a window and why does it not work on the first one? (2010-02-20)
Next: Some Early Topics
From: Dmitry A. Soshnikov on 23 Feb 2010 05:31 On Feb 23, 1:19 am, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: [...] > > It could be argued that this is not a bug. The spec's conformance > section explicitly allows objects to have properties in addition to > those specified. There would be a problem if the - arguments.length - > changed when - arguments[0] - was added to the object, but as that does > not happed the result is an arguments object with all the specified > properties having all the specified values and behaviour, and no more > than the additional properties that ES3 allows. > Many things in ES3 could be debatable as many things (no less than spec itself) are ambiguous, but that was recognized (by many implementations) as a bug as spec says exactly (ES3, 10.1.8): | ... is the number of *actual parameter | values supplied by the caller* Whether it's debatable and ambiguous - that's already another question. /ds
From: Dmitry A. Soshnikov on 23 Feb 2010 05:48 On Feb 23, 4:04 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [...] > > If this is not a bug ... > It's a bug. The question and the meaning are very ambiguous (from the human viewpoint), but regarding to spec (which is itself ambiguous in many moments) - it's a bug. > > It seems odd for a program to expect the `arguments` object not to have > a "0" property at that point. > Yes, it could be so. But from the other side: current spec's behavior is a consequence of that quantity of formal parameters - is <constructor>.length, and the quantity of the _actual_ parameters - is `arguments.length'. For what reason there should be 1 or 2, but not (correctly) 0? And if they would made that local variable from the activation object would share its name also in this case (when there's no any parameter passed) - it's also be ambiguous - e.g. for check where user *really* passed something to function (could be useful with overloading by parameters length). So abstractly this case turns out like function has no parameters at all, and `x' - is just a local variable: function foo(x, y) { x = 10 } foo(20, 30) => foo(x, y) { x = 10 } foo(40) => foo(x) { x = 10 } foo(50) => foo() { [var ]x = 10 } > > The oddness of the situation may be a good > reason the chrome bug (AISI) went on unnoticed for so long. > Maybe. They can write a suggestion to change the behavior (but not arguing that spec allows any other additional properties - as in this cases - all the spec can be doubtful, but providing alternative unequivocal meaning, taking into account all the existing features). But also can be that they just forgot to fix it according to ES3 10.1.8. /ds
From: Richard Cornford on 23 Feb 2010 06:24 On Feb 23, 10:31 am, Dmitry A. Soshnikov wrote: > On Feb 23, 1:19 am, Richard Cornford wrote: > [...] >> It could be argued that this is not a bug. The spec's conformance >> section explicitly allows objects to have properties in addition to >> those specified. There would be a problem if the - arguments.length >> - changed when - arguments[0] - was added to the object, but as >> that does not happed the result is an arguments object with all >> the specified properties having all the specified values and >> behaviour, and no more than the additional properties that ES3 >> allows. > > Many things in ES3 could be debatable as many things (no less than > spec itself) are ambiguous, but that was recognized (by many > implementations) as a bug as spec says exactly (ES3, 10.1.8): > > | ... is the number of *actual parameter > | values supplied by the caller* That is the specification for the - length - property of the - arguments - object, but do we have any evidence of an environment where the - length - property is incorrect? My quick tests of Chrome show the addition of an - arguments[n] - when assigning to a corresponding formal parameter for which no actual argument was passed, but that the - arguments.length - value is not altered by this action (and so does not become incorrect). The - length - property is not specified as relating to the number of 'integer index' properties of the - arguments - object, and the only 'integer index' properties specified are those where the integer would be less than - length -. > Whether it's debatable and ambiguous - that's already another > question. ECMA 262 3rd Ed. specifies the argument object's [[Prototype]], its callee, its length and "non-negative integer" properties "less than the value of the length property". This "bug" does not present any evidence of any of these specified properties having incorrect values or behaviours. The conformance section (1) starts out stating that: "A conforming implementation of ECMAScript must provide and support all the types, values, objects, properties, functions, and program syntax and semantics described in this specification.", but for an arguments object all of the properties, syntax and semantics appear to be correct where Chrome is concerned. The conformance section also says: "A conforming implementation of ECMAScript is permitted to provide additional types, values, objects, properties, and functions beyond those described in this specification.", and what we have is evidence of properties of an arguments "beyond" (literally in this case) to those specified. You can argue that the situation as it manifests itself in Chrome is a bad idea, and observe that others have made different (even better) decisions, but I cannot see how this violates the specification in any way. Therefore it is not an implementation bug. Richard.
From: Dmitry A. Soshnikov on 23 Feb 2010 14:15 On Feb 23, 2:24 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On Feb 23, 10:31 am, Dmitry A. Soshnikov wrote: > > > > > On Feb 23, 1:19 am, Richard Cornford wrote: > > [...] > >> It could be argued that this is not a bug. The spec's conformance > >> section explicitly allows objects to have properties in addition to > >> those specified. There would be a problem if the - arguments.length > >> - changed when - arguments[0] - was added to the object, but as > >> that does not happed the result is an arguments object with all > >> the specified properties having all the specified values and > >> behaviour, and no more than the additional properties that ES3 > >> allows. > > > Many things in ES3 could be debatable as many things (no less than > > spec itself) are ambiguous, but that was recognized (by many > > implementations) as a bug as spec says exactly (ES3, 10.1.8): > > > | ... is the number of *actual parameter > > | values supplied by the caller* > > That is the specification for the - length - property of the > - arguments - object Not only, the spec says about the concrete and exact case *when arguments properties share their values with corresponding variables of the activation object*. And this case is related to `arguments.length'. Sure, arguments can be augment with new properties on runtime context phase (which executes after entering the context phase at which `arguments' (and all the other stuff) is created). > but do we have any evidence of an environment > where the - length - property is incorrect? No, with `arguments.length' everything's OK - in all implementations - it shouldn't be changed as `arguments' is not an array, thus has no overloaded [[Put]] for that. So it should be always 0 in this case. > My quick tests of Chrome > show the addition of an - arguments[n] - when assigning to a > corresponding formal parameter for which no actual argument was > passed, but that the - arguments.length - value is not altered by > this action (and so does not become incorrect). > With `.length' that's OK, as mentioned above, but Chrome makes error with *fact of sharing* the value of local variable, and the case when this fact should be true is described in 10.1.8 and depends on actual `arguments.length' analyzed on entering the context. The conformant implementation (as I see it) is: function foo(x) { x = 10; alert(arguments[0]); // should undefined arguments[0] = 100; alert([ arguments[0], // should be 100 x, // should be 10, as doesn't share arguments.length // should be 0, as [[Get]] isn't overloaded ]); } foo(); And only in Chrome we have "100, 100, 100, 0", meanwhile in other: "undefined, 100, 10, 0". > The - length - property is not specified as relating to the number of > 'integer index' properties of the - arguments - object, and the only > 'integer index' properties specified are those where the integer would > be less than - length -. > The main goal of the last bullet of 10.1.8 even is not in `length' (although, in `length' also), but in specifying *exact behavior and the case* when implementation should share `arguments' index-properties values and local variables of the activation object. > > You can argue that the situation as it manifests itself in Chrome is a > bad idea, and observe that others have made different (even better) > decisions > Yeah, some (all?) other implementations recognize it as bug. For example, I found in code of SpiderMonkey comment related to bug mentioned above by Garrett where implementors also agree that the behavior of 10.1.8 should be treated so: <URL: http://mxr.mozilla.org/mozilla/source/js/src/jsfun.c#210> > but I cannot see how this violates the specification in any > way. Therefore it is not an implementation bug. > As I mentioned, it's in the last bullet of the 10.1.8, where the exact case when `arguments' and local variables should be shared is described. /ds
From: Richard Cornford on 24 Feb 2010 06:43
On Feb 23, 7:15 pm, Dmitry A. Soshnikov wrote: > On Feb 23, 2:24 pm, Richard Cornford wrote: >> On Feb 23, 10:31 am, Dmitry A. Soshnikov wrote: >>> On Feb 23, 1:19 am, Richard Cornford wrote: >>> [...] >>>> It could be argued that this is not a bug. The spec's conformance >>>> section explicitly allows objects to have properties in addition >>>> to those specified. There would be a problem if the - >>>> arguments.length - changed when - arguments[0] - was added to >>>> the object, but as that does not happed the result is an >>>> arguments object with all the specified properties having all >>>> the specified values and behaviour, and no more than the >>>> additional properties that ES3 allows. > >>> Many things in ES3 could be debatable as many things (no less >>> than spec itself) are ambiguous, but that was recognized (by >>> many implementations) as a bug as spec says exactly (ES3, >>> 10.1.8): > >>> | ... is the number of *actual parameter >>> | values supplied by the caller* > >> That is the specification for the - length - property of the >> - arguments - object > > Not only, So which other value represents "the number of *actual parameter values supplied by" the caller*"? > the spec says about the concrete and exact case *when > arguments properties share their values with corresponding > variables of the activation object*. Only "In the cases when arg is less then the number of formal parameters for the function" and after constraining arg to all "non- negative integers" "less then the value of the length property". > And this case is related to `arguments.length'. Sure, arguments > can be augment with new properties on runtime context phase > (which executes after entering the context phase at which > `arguments' (and all the other stuff) is created). I don't understand that last sentence. >> but do we have any evidence of an environment >> where the - length - property is incorrect? > > No, with `arguments.length' everything's OK - in all > implementations - it shouldn't be changed as `arguments' is > not an array, thus has no overloaded [[Put]] for that. So > it should be always 0 in this case. > >> My quick tests of Chrome >> show the addition of an - arguments[n] - when assigning to a >> corresponding formal parameter for which no actual argument was >> passed, but that the - arguments.length - value is not altered >> by this action (and so does not become incorrect). > > With `.length' that's OK, as mentioned above, but Chrome makes > error with *fact of sharing* the value of local variable, and > the case when this fact should be true is described in 10.1.8 > and depends on actual `arguments.length' analyzed on entering > the context. The conformant implementation (as I see it) is: > > function foo(x) { > x = 10; > alert(arguments[0]); // should undefined Based on what? In this case - arguments.length - is zero, and so there is no specified value or behaviour for an - arguments[0] - property in this case. > arguments[0] = 100; > alert([ > arguments[0], // should be 100 Yes it should, as the - arguments[0] - property has just been assigned that value. > x, // should be 10, as doesn't share That is much harder to justify. While successful assignment would not normally be expected to have side effects on the values of the properties of other objects I don't see anything that forbids this. > arguments.length // should be 0, as [[Get]] isn't overloaded > ]); > > } > > foo(); > > And only in Chrome we have "100, 100, 100, 0", meanwhile in > other: "undefined, 100, 10, 0". But as there is no 'correct' outcome to be derived from the specification it is not possible to declare either to be wrong. Interactions with 'integer index' properties of the - arguments - object that are equal to or greater than - arguments.length - are not specified at all. >> The - length - property is not specified as relating to the >> number of 'integer index' properties of the - arguments - >> object, and the only 'integer index' properties specified >> are those where the integer would be less than - length -. > > The main goal of the last bullet of 10.1.8 even is not in > `length' (although, in `length' also), but in specifying > *exact behavior and the case* when implementation should > share `arguments' index-properties values and local > variables of the activation object. Whatever the motivation of the section, the wording of the section specifies exact behaviour for a length property and all non-negative 'integer index' properties that are less than the length value. It says nothing about the existence (or non-existence), value or behaviour of 'integer index' properties that are equal to or greater than length; there are no constraints placed on such properties in that section. It would be possible to argue that whatever is not specified is therefore forbidden, but that position would instantly collapse at the third paragraph of the conformance section; you cannot forbid all that is not specified at the same time as allowing "additional types, objects, properties and functions beyond those described in this specification". Section 10.1.8 specifies the values and behaviour of non-negative integer index properties of the - arguments - object that are less than the - arguments.length - value, and it stops there. Beyond that the language's conformance rules allow anything that does not contradict what is specified. >> You can argue that the situation as it manifests itself >> in Chrome is a bad idea, and observe that others have >> made different (even better) decisions > > Yeah, some (all?) other implementations recognize it as bug. You cannot assume that. It is entirely possible that where it is recognised at all the behaviour chosen was chosen because it was seen as sensible. > For example, I found in code of SpiderMonkey comment related > to bug mentioned above by Garrett where implementors also > agree that the behavior of 10.1.8 should be treated so: > > <URL:http://mxr.mozilla.org/mozilla/source/js/src/jsfun.c#210> Is that an appeal to authority? Individuals, including those working on script engine software, are capable of misinterpreting the specification, reading more in that is there, or even just expressing themselves imprecisely/poorly. (just as I am, which is what makes having this discussion in public worthwhile. Burred in the spec somewhere they may be something that would make this Chrome feature an ECMAScript implementation bug. It is not in section 10.1.8, but that does not mean that nobody here will be able to point something out). >> but I cannot see how this violates the specification in any >> way. Therefore it is not an implementation bug. > > As I mentioned, it's in the last bullet of the 10.1.8, where > the exact case when `arguments' and local variables should be > shared is described. If it is there, by all means cite the text that imposes constraints on the existance, values or behaviour of 'integer index' properties of the - arguments - object that are equal to or greater than - arguments.length -. I don't see it. Richard. |