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 11:30 On Feb 24, 6:44 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On Feb 24, 2:57 pm, Dmitry A. Soshnikov wrote: > > - `arguments.length' == 0, right? > > > - 0 is less 1, right? > > Less than ..., but yes. Thanks; typos. > > > - 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. > As I told, I understand this position but think that it's too formal and thus in this particular case is useless (who needs implementations based on catching the "law's holes"?). Everybody understands that this just a bug, regardless references to conformance section. > > 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. > Well, I got your position, although I think it useless and believe as just playing on words (I am fair, whether you like it or not). As I said, there could be many ambiguous meanings and treating in the ES3 specification. As a simple abstract example (to show you how playing on words it's possible to justify not static, but dynamic scope in ES): From 8.6.2: [[Scope]] - "A scope chain that defines the environment in which a Function object is *executed*." Everybody understands, that last word of the sentence - *executed* - means scope chain where function context will resolve its identifiers (which is set statically (lexically) on function's creation). But if to start playing on words, you can treat this word - *executed* - differently, saying that function is created in on context, but may be *executed* in completely different context (and its scope chain) taking justifying dynamic scope instead of static lexical scope used in ES: var x = 10; function () { var x = 20; // function is *created* return function () { alert(x); }; } var bar = foo(); // function is *executed* bar(); // 20 But to play on words, it's possible to justify wrong behavior when bar's call will return 10 - saying, "[[Scope]] - is a scope chain, when function is *executed*, and bar is executed in scope chain of the global context, so our implementation with dynamic scope is not an implementation bug, at least not by specification". But who needs this playing on words, if everybody understands that *executed* means "when function's context will resolve its identifiers, which is set *statically* when function is *created*". That was just an example. > When people use the specification to justify their positions Strange, I thought all that time, that it's you who wants to "justify his positions". I'm just interesting in _objective_ truth without justifying any position. Anyway, thanks for discussion. /ds
From: Dmitry A. Soshnikov on 24 Feb 2010 12:48 On Feb 24, 7:30 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: [...] > > As I told, I understand this position but think that it's too formal > and thus in this particular case is useless And yeah, fair addition: if you admit that _objectively_ behavior of Chrome is wrong in this particular case (and as a consequence - behavior of other implementations is correct), I'll admit that your position with: "if index-properties are not negative and greater than `arguments.length', their behavior is not controlled at all by 10.1.8" could be _"arguable"_ (which still doesn't mean that Chrome is correct). But _very-very formally_ ;) /ds
From: Richard Cornford on 24 Feb 2010 13:20 On Feb 24, 4:30 pm, Dmitry A. Soshnikov wrote: > On Feb 24, 6:44 pm, Richard Cornford wrote: >> On Feb 24, 2:57 pm, Dmitry A. Soshnikov wrote: >>> - `arguments.length' == 0, right? <snip> >>> 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. > > As I told, I understand this position but think that it's too > formal and thus in this particular case is useless (who needs > implementations based on catching the "law's holes"?). It is strange to be describing specification text that you labelled as an "algorithm" as "too formal". It is the business of specifications to precisely state whatever they need to state. In this case, not only does this section in the specification limit its assertions to cases were 'arg' is a non-negative integer that is less then the length but it goes on to make to references to "this property" where the only properties that it could be referring to are those created for each non-negative integer, 'arg', less then the length. | For each non-negative integer, arg, less than the value of the | length property, _a_property_is_created_ with ... . | The initial value of _this_property_ is ... | _this_property_ shares its value with ... | changing _this_property_ changes the ... . Very simply, the specification asserts a set of requirements that are limited in scope and all of the behaviour that is being objected to is occurring outside of that scope (that is 'scope' in the non-javascript sense). > Everybody understands that this > just a bug, regardless references to conformance section. It is not an ECMAScript implementation bug, and any objection to it is not justified by ECMA 262 3rd Ed. >>> 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. > > Well, I got your position, although I think it useless and > believe as just playing on words So you haven't got it. The wording of that section of the spec is not that ambiguous or open to interpretation. It means what it says, and specifies what it specifies. It requires the creation of a (possibly empty) set of properties, states the source for initial values for those properties, and it asserts a linkage between some of those properties and a functions formal parameters. But is says noting about any properties of arguments objects that are not in that set. > (I am fair, whether you like it or not). As I > said, there could be many ambiguous meanings and treating in > the ES3 specification. As you have been asserting that the truth of this is to be seen in the last bullet point in section 10.1.8, only the possible ambiguities of that section are significant. > As a simple abstract example (to show you how playing > on words it's possible to justify not static, but dynamic > scope in ES): That isn't going to work. > From 8.6.2: > > [[Scope]] - "A scope chain that defines the environment in which a > Function object is *executed*." This does not make any requirements that influence the behaviour of ECMAScript. If you want to know how scopes work it would be necessary to look the various sections that define the mechanics of their handling. > Everybody understands, that last word of the sentence - > *executed* - means scope chain where function context will > resolve its identifiers (which is set statically (lexically) > on function's creation). Well, no. the scope against which Identifiers are executed is determined upon entering an execution context, by implying the Activation/Variable object and the list of objects assigned to the function's [[Scope]] property. The former object is different for each execution of the function, and only the latter comes into existence when the function is created. > But if to start playing on words, you can treat this word > - *executed* - differently, saying that function is created > in on context, but may be *executed* in completely different > context If "context" here means 'Execution Context' then that is precisely what happens. > (and its scope chain) taking justifying dynamic scope instead > of static lexical scope used in ES: I don't see it. > var x = 10; > function () { > var x = 20; > // function is *created* > return function () { > alert(x); > }; > > } > > var bar = foo(); > > // function is *executed* > bar(); // 20 > > But to play on words, it's possible to justify wrong behavior > when bar's call will return 10 - saying, "[[Scope]] - is a > scope chain, when function is *executed*, and bar is executed > in scope chain of the global context, so our implementation > with dynamic scope is not an implementation bug, at least not > by specification". No, there you have an implementation bug because the specification contradicts the behaviour described. The way in which the scope of an execution context is assembles is layer down, and the way in which its component parts are created is also specified. Combine those specifications with the Identifier resolution algorithm and the correct behaviour follows. > But who needs this playing on words, Nobody. There is enough else in the spec to understand the precise behaviour of scopes in javascript. > if everybody understands > that *executed* means "when function's context will resolve its > identifiers, which is set *statically* when function is *created*". If. > That was just an example. > > > When people use the specification to justify their positions > > Strange, I thought all that time, that it's you who wants to > "justify his positions". I am trying to make it understood. > I'm just interesting in _objective_ truth without > justifying any position. But you appear to be having trouble seeing it. > Anyway, thanks for discussion. As you like. Richard.
From: Richard Cornford on 24 Feb 2010 13:31 On Feb 24, 5:48 pm, Dmitry A. Soshnikov wrote: > On Feb 24, 7:30 pm, Dmitry A. Soshnikov wrote: > [...] >> As I told, I understand this position but think that it's >> too formal and thus in this particular case is useless > > And yeah, fair addition: if you admit that _objectively_ > behavior of Chrome is wrong in this particular case I don't. "Wrong" needs objective (or even formal) criteria, which are available but are not judging against Chrome. My subjective judgment is that Chrome is wrong to do what it is doing, but that is because I can see no value in doing it, and a downside that could be avoided by not doing it. > (and as a consequence - > behavior of other implementations is correct), No, they are correct independently of whatever Chrome may be doing (or of my admitting anything). > I'll admit that your > position with: "if index-properties are not negative and > greater than `arguments.length', their behavior is not > controlled at all by 10.1.8" could be _"arguable"_ (which > still doesn't mean that Chrome is correct). It may mean that Chrome is not incorrect. > But _very-very formally_ ;) How many programming languages have informal specifications? How would that work? Richard.
From: Garrett Smith on 24 Feb 2010 15:51
Richard Cornford wrote: > On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote: >> On Feb 24, 2:43 pm, Richard Cornford wrote: [...] > >> 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. > Chrome has an interpretation of the spec that is different from what is specified in Ecma 262 r3. What Chrome does is not explicitly mentioned and so is not fully accommodated. OTOH, Chrome's behavior is not explicitly forbidden, either. It is not correct to expect that a browser won't do that. > 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. > OK. >>>> 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. > The section on the arguments object states how and when properties are added. Chrome fills that in, but colors outside the lines a bit. In doing that, it is going against what I read as the intent of the spec, which is to describe precisely when properties are added to arguments object. If arguments is an Object object, then according to section 15.2.5, it should not have additional properties. | 15.2.5 Properties of Object Instances | | Object instances have no special properties beyond those inherited | from the Object prototype object. Arguments is an Object instance and so can be expected to have no additional properties (obviously excepting those that are explicitly stated). -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |