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 24 Feb 2010 07:56 On Feb 24, 2:43 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: [...] > > >> 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*"? > Seems you didn't understand correctly, by "not only" I meant that 10.1.8 says not only the length property but also about the exact case when properties of `arguments' object and and corresponding formal parameters should be shared. > > 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". > Do I understand correctly that you argue about that if arguments.length == 0, than implementation can share corresponding formal *first* parameter as index-property of the `arguments[0]' is *equal to* 0, but not less as told in spec? If so, sorry, this is just a _too formal_ attempt to think out "how could it be if ...". And doesn't it mean that for `arguments[1]' shouldn't share the corresponding formal parameter (1 < 0, where 0 - is the `arguments.length')? But it does. As it does (wrong) for `arguments[0]'. Your current arguing reminds some case in court when everybody understands that it is wrong, but because of _some formal ambiguity_ (a "formal hole in the law") is will be justified. Sorry, no, it won't. > > 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. > Doesn't matter, I meant that it's possible to add new properties to `arguments' object (but they shouldn't affect the `.length' property, what I said in another sentence). > > 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. > I said above - it's just an attempt to be hooked for ambiguity of the specification. If Chrome is correct by your words, than it shouldn't share `y' (let's assume it's the second parameter) and `arguments[1]' in case when no parameters are passed. But Chrome shares them in all that cases, which is wrong. Referencing to conformance section also isn't fit here - because implementation can create any other properties (as many as it want), but shouldn't disturb the description of concrete algorithm (10.1.8 in this case; see for `arguments[1]' then if you still want to argue about 0 == 0, but not less than). > > 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. > Yeah, that's true (any side effect could be, which specification doesn't forbid), but this exact case is forbidden by 10.1.8 (again, you can choose to analyze arguments[1], y, and the case when no parameters passed to (x, y) function). > > 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. > Mentioned above, it seems like formal catching the hole in ambiguous specification description, but I can't find useful application of it. Then use arguments[1] and y, when .length will be 0, and Chrome will try to share 1 which is grater than 0. Do I understand correctly that for you statements "1 is grater than 0" (with which you're trying to argue) and "0 is less than 1" are not equivalent for this case? > >> 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. > Yeah, I mentioned it above. > 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. > On implementation level this should be so. Some ambiguous cases should be treated as logical as possible, but without finding "law holes" and choosing this way to implement (and moreover, argue after than referencing on it). > > 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? Strange to hear that. Never. Seems, you confuse me to someone. But if you insist: this is just _an example_. > 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). > Yes, it could be so, but I think this case is clear although is very ambiguous and can be appellate with references which you mention. The other question - what is the big deal of that too formal appellations for the implementation level? I don't see a big. Although, I clearly understand your position. /ds
From: Richard Cornford on 24 Feb 2010 09:09 On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote: > On Feb 24, 2:43 pm, Richard Cornford wrote: > [...] >>>> 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*"? > > Seems you didn't understand correctly, by "not only" I meant that > 10.1.8 says not only the length property but also about the exact > case when properties of `arguments' object and and corresponding > formal parameters should be shared. No, section 10.1.8 specifies a minimum set of properties of the - arguments - object that will share values with formal parameters. It does not constrain the values or behaviours of any - arguemnts - object 'integer index' properties that are not in that set. >>> 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". > > Do I understand correctly that you argue about that if > arguments.length == 0, than implementation can share corresponding > formal *first* parameter as index-property of the `arguments[0]' > is *equal to* 0, but not less as told in spec? I am pointing out that there are boundaries to what is being specified in 10.1.8, and that as the behaviour that is being subject to criticism is outside of those boundaries section 10.1.8 does not apply to it. > If so, sorry, this > is just a _too formal_ attempt to think out "how could it be if > ...". And doesn't it mean that for `arguments[1]' shouldn't share > the corresponding formal parameter (1 < 0, where 0 - is the > `arguments.length')? But it does. As it does (wrong) for > `arguments[0]'. I don't understand that sentence. > Your current arguing reminds some case in court when everybody > understands that it is wrong, but because of _some formal > ambiguity_ (a "formal hole in the law") is will be justified. > Sorry, no, it won't. Yes, of course. But the accusation being made is taking the form of accusing Chrome of violating ECMA 262 3rd Ed; that the behaviour exhibited represents an ECMAScript implementation bug. This accusation is false, as the behaviour exhibited is fully accommodated by the specification. Now if someone wanted to accuse Chrome of doing something that was stupid, not a good idea, of no practical use or help to anyone, etc. then that is all fine (and probably true), but let us not call it an ECMAScript implementation bug unless it is an ECMAScript implementation bug. >>> 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. > > Doesn't matter, I meant that it's possible to add new properties > to `arguments' object (but they shouldn't affect the `.length' > property, what I said in another sentence). > >>> 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. > > I said above - it's just an attempt to be hooked for ambiguity > of the specification. There is no ambiguity; the specification does not define anything about an - arguments[0] - property in this case, but does allow for properties and behaviour beyond what it does specify. > If Chrome is correct by your words, My words aren't important; Chrome is 'correct' by specification (in the sense that what it is doing is not incorrect by the specification). > than it shouldn't share `y' (let's assume it's the second > parameter) and `arguments[1]' in case when no parameters > are passed. Why? If the existence, value and behaviour of - arguments[0] - is beyond what is specified then the same will apply to - arguments[1] -, etc. > But Chrome shares them in all that cases, which is wrong. But only wrong by opinion, not wrong according to the specification. > Referencing to conformance section also isn't fit here - > because implementation can create any other properties > (as many as it want), but shouldn't disturb the description > of concrete algorithm (10.1.8 The algorithm is bound by zero and - < arguments.length -. 'integer index' properties outside of that range are not specified, and so they cannot "disrupt" the algorithm. > in this case; see for `arguments[1]' then if you still want to > argue about 0 == 0, but not less than). > >>> 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. > > Yeah, that's true (any side effect could be, which specification > doesn't forbid), but this exact case is forbidden by 10.1.8 I don't see any text in 10.1.8 that does forbid it. I see text that states what values and properties can be expected of non-negative 'inter index' properties that are less then - arguments.length -, but that is where it stops. > (again, > you can choose to analyze arguments[1], y, and the case when no > parameters passed to (x, y) function). > >>> 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. > > Mentioned above, it seems like formal catching the hole in ambiguous > specification description, There is still no ambiguity; the specification specifies what it specifies, and beyond that there is the conformance section. > but I can't find useful application of it. > Then use arguments[1] and y, when .length will be 0, and Chrome > will try to share 1 which is grater than 0. Do I understand > correctly that for you statements "1 is grater than 0" (with > which you're trying to argue) and "0 is less than 1" are not > equivalent for this case? Less than - arguemnts.length - is what ECMA 262 specifies, and greater than or equal is left unspecified. >>>> 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. > > Yeah, I mentioned it above. Mentioned that there are no constraints on the existence, values or behaviour of 'integer index' properties that are equal to or greater than length? <snip> >> (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). > > Yes, it could be so, but I think this case is clear although is very > ambiguous and can be appellate with references which you mention. The > other question - what is the big deal of that too formal appellations > for the implementation level? I don't see a big. I don't understand that. > Although, I clearly understand your position. OK, so is what Chrome is doing an ECMAScript implementation bug or not? Richard.
From: Dmitry A. Soshnikov on 24 Feb 2010 09:57 On Feb 24, 5:09 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: [...] > > > than it shouldn't share `y' (let's assume it's the second > > parameter) and `arguments[1]' in case when no parameters > > are passed. > > Why? If the existence, value and behaviour of - arguments[0] - is > beyond what is specified then the same will apply to - arguments[1] -, > etc. > Although, I won't touch the case when 0 == 0, so it's allowed, as I said that this is just a formal playing on words, but is not about correct understanding, I ask: function foo(x, y) { y = 10; alert(arguments[1]); } foo(); So, what we have: - `arguments.length' == 0, right? - 0 is less 1, right? - 1 is greater than 0, right? - 1 is *not* less than 0, right? - this is for you 10.1.8 If the last point is correct, why does Chrome share y and [1]? As said absolutely clear: "In the case when arg is less than the number of formal parameters for the Function object, this property shares its value with the corresponding property of the activation object". Here `arg' (1) is not less than the number of formal parameters (0), so Chrome is wrong, right? If you'll answer "no", do I understand that for you "1 is greater than 0" is not the same as "0 is less than 1"? If so, I should stop on this point, as this is just the play on words (which is not so useful, don't you think so?). > > > Although, I clearly understand your position. > > OK, so is what Chrome is doing an ECMAScript implementation bug or > not? > Sure not ;) Current Chrome's implementation has a bug regarding to 10.1.8 regardless _formal_ catches and references to conformance section. By the way, what the reason of your argue? /ds
From: Dmitry A. Soshnikov on 24 Feb 2010 10:11 On Feb 24, 5:57 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > > Sure not ;) Current Chrome's implementation has a bug regarding to > 10.1.8 regardless _formal_ catches and references to conformance > Typo: "Sure not"* is "Sure yes, Chrome has bug" as follows from other part of the following statement. /ds
From: Richard Cornford on 24 Feb 2010 10:44
On Feb 24, 2:57 pm, Dmitry A. Soshnikov wrote: > On Feb 24, 5:09 pm, Richard Cornford wrote: > [...] >>> than it shouldn't share `y' (let's assume it's the second >>> parameter) and `arguments[1]' in case when no parameters >>> are passed. > >> Why? If the existence, value and behaviour of - arguments[0] >> - is beyond what is specified then the same will apply to >> - arguments[1] -, etc. > > Although, I won't touch the case when 0 == 0, so it's > allowed, as I said that this is just a formal playing on > words, but is not about correct understanding, I ask: > > function foo(x, y) { > y = 10; > alert(arguments[1]); > > } > > foo(); > > So, what we have: > > - `arguments.length' == 0, right? > > - 0 is less 1, right? Less than ..., but yes. > - 1 is greater than 0, right? > - 1 is *not* less than 0, right? - this is for you 10.1.8 > > If the last point is correct, why does Chrome share y and [1]? > As said absolutely clear: "In the case when arg is less than the > number of formal parameters for the Function object, this property > shares its value with the corresponding property of the activation > object". This only occurs after 'arg' has been defined as: "For each non- negative integer, arg, less than the value of the length property, ...". If 'arg' is a non-negative integer less than the value of the length, and the length is zero, then there are no value that are 'arg', and if there are no values that are 'arg' then there are no cases "when arg is less than the number of formal parameters for the Function object". In that case no 'integer index' properties of the arguments object are defined by the specification, and so any that do exist must exist under the provisions of the conformance section and may have any value or behaviour that they want. > Here `arg' (1) is not less than the number of formal parameters (0), There is no 'arg' that has the value 1 when - arguments.length - is zero, as then there are no values that satisfy "non-negative integer, arg, less than the value of the length property". > so Chrome is wrong, right? Not according to the specification. > If you'll answer "no", do I understand that for you "1 is greater than > 0" is not the same as "0 is less than 1"? I am saying that the set of non-negative integers that are less then zero is empty. > If so, I should stop on this point, as this is just the play on > words (which is not so useful, don't you think so?). A play on words is not useful, but understanding the applicable specification for the language you are using is. >>> Although, I clearly understand your position. > >> OK, so is what Chrome is doing an ECMAScript implementation bug or >> not? > > Sure not ;) Current Chrome's implementation has a bug regarding to > 10.1.8 regardless _formal_ catches and references to conformance > section. (Taking into account your correction of the above) I still see nothing in that section that applies to 'integer index' properties of an - arguments - object that are greater than or equal to - arguments.length -. > By the way, what the reason of your argue? You mean beyond demonstrating that when I said that this was "arguable" I was telling the truth? When people use the specification to justify their positions I prefer to see that the specification does justify those positions. Mere opinions should be exposed as such, and justified (or not) on other grounds. Richard. |