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: Richard Cornford on 25 Feb 2010 02:41 Garrett Smith wrote: > Richard Cornford wrote: >> On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote: >>> On Feb 24, 2:43 pm, Richard Cornford wrote: <snip> >>> 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. ECMA 262 specifies its own interpretation? > What Chrome does is not explicitly mentioned and so is > not fully accommodated. The conformance section requires that the things that are mentioned do happen. Anything that is not mentioned is not constrained or forbidden by the specification. Indeed, the third paragraph of the conformance section implies that anything that is not mentioned is explicitly allowed. > 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. > <snip> >> 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. No, the specification defines a set of properties (their values and behaviour) that will be added to an arguments object. Possible properties beyond those specified are not covered at all. > Chrome fills that in, Chrome satisfies the requirements of the specification, in that it adds the properties of the arguments object that are specified, and gives then the correct values and behaviour. > but colors outside the lines a bit. Only in the sense that it does things beyond what is specified that are neither required nor forbidden. > In doing that, it is going against what I read as the > intent of the spec, You shouldn't try to read intent in the spec, the result will be subjective and personal. Read the words in the spec. > which is to describe precisely when properties are added > to arguments object. If that were the intent it would have been trivial to write the wording that would make it mandatory. The absence of those words is significant. > 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. (I assume that this means that you have abandoned the idea that section 10.1.8 contradicts the behavior exhibited by Chrome. i.e. your bug report is incorrect in its assertion that it does.) That section is best considered in comparison with similar section on the properties of instances of other types, such as:- | 15.3.5 Properties of Function Instances | | In addition to the required internal properties, every | function instance has a [[Call]] property, a [[Construct]] | property and a [[Scope]] property (see sections 8.6.2 and | 13.2). The value of the [[Class]] property is "Function" It does not exclude the possibility of Object instances having properties beyond those specified, it just states that ECMA 262 does not define any special properties for those particular object instances. | Conformance | 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. | ... | A conforming implementation of ECMAScript is permitted to | provide additional types, values, objects, properties, and | functions beyond those described in this specification. | In particular, a conforming implementation of ECMAScript is | permitted to provide properties not described in this | specification, and values for those properties, for objects | that are described in this specification. It doesn't matter whether the object is the normal object object or the arguments object specifically, a "conforming implementation" may "provide properties not described in this specification" "for objects that are described in this specification", so long as doing so does not prevent it from providing "all the types, values, objects, properties, functions, and program syntax and semantics described in this specification". You cannot prevent, exclude or forbid anything that is not specified except by showing that it contradicts something that is specified. > Arguments is an Object instance and so can be expected to > have no additional properties (obviously excepting those > that are explicitly stated). No, an arguments object may have properties beyond those explicitly specified. Richard.
From: Dmitry A. Soshnikov on 25 Feb 2010 04:07 On Feb 24, 9:20 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: <snip> > > | 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). > Richard, as I said, I can see that you (OK, fairly) caught the _bad formulation_ of the 10.1.8 and from this viewpoing it's *de jure* could be (_very-very formaly_) justified. But *de facto* - this hole with bad formulation is not so essential, as _objectively_ it should be treated as treated in some other implementation. The only reason why I'm saying this just because I'm interested in theory. And, yeah, forming _subjectively_ (that's what exactly you're doing) _could_ justify it on _objective de juro_. But, repeat, _objective de facto_ Chrome didn't understood it correctly (as SpiderMonkey did also firstly, but then fixed this bug). > > So you haven't got it. Got, got, be sure, and told my meaning. > If you want to know how scopes work it would be necessary > to look the various sections that define the mechanics of their > handling. > Thanks, I know how scope(s) work(s) (in ES and in general theory). > > 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. > Thanks, I know what is scope chain and how it works. Didn't I say that it was just an abstract example to demonstrate 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*". > > If. > Yeah, if. But I hope so. > > > 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 understand you. And understand the spec. Actually, that's even not my *fault* that this behavior de facto should be not like in Chrome, but de jure, I can accept (very-very formal with subjective formulation which "shows a good sides of the position") it. But as I said, for the particular case (on implementation level) it's useless. > > I'm just interesting in _objective_ truth without > > justifying any position. > > But you appear to be having trouble seeing it. > Please, don't use statement forms about troubles seeing it. I can statement absolutely the same regardless the "success" subjective formulation which is based on the hole of the spec's forumlation. > > Anyway, thanks for discussion. > > As you like. > As you. Although, I meant that this de juro subjective formulation is interesting (meanwhile, unfortunately useless). /ds
From: Dmitry A. Soshnikov on 25 Feb 2010 04:36 On Feb 24, 9:31 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > 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 > > 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. > OK, let's accept 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). > Yep, I think so too and regardless also my admitting. > > 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. > Useless objective de juro (based on subjective formulation which caught bad formulation of the spec; by the way - funny combination: "objective... based on subjective") for implementers is not so essential rather than objective de facto regardless bad formulations of the specification. But for the analysis of the theory, this de juro forumlation - is interesting, yeah. > > But _very-very formally_ ;) > > How many programming languages have informal specifications? How would > that work? > First, almost all specifications and technical documents have ambiguous moments, and erratas. Secondly, we should distinguish meaning of "formal algorithms" (which are the basis of any technical specification) and subjective treating of words (also known as playing on words to show the "good" side of the position) based on caught bad formulations of that "formal algorithms". So, sure specification algorithms should be formal, but it doesn't exclude the fact of misconceptions and bad formulations. /ds
From: Garrett Smith on 25 Feb 2010 12:35 Richard Cornford wrote: > Garrett Smith wrote: >> Richard Cornford wrote: >>> On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote: >>>> On Feb 24, 2:43 pm, Richard Cornford wrote: > <snip> >>>> 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. > > ECMA 262 specifies its own interpretation? > >> What Chrome does is not explicitly mentioned and so is >> not fully accommodated. > > The conformance section requires that the things that are mentioned do > happen. Anything that is not mentioned is not constrained or forbidden > by the specification. Indeed, the third paragraph of the conformance > section implies that anything that is not mentioned is explicitly allowed. > Ah, no. The conformance section does not imply that "anything that is not mentioned is explicitly allowed." That conformance section: | ..."A conforming implementation of ECMAScript is permitted to provide | additional types, values, objects, properties, and functions beyond | those described in this specification." I see a list of "types, values, objects, properties, and functions". Not "anything". A conforming implementation that features existing built-in Object, is not permitted to provide additional properties to that Object. AIQB: | 15.2.5 Properties of Object Instances | Object instances have no special properties beyond those inherited | from the Object prototype object. >> 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. >> > <snip> >>> 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. > > No, the specification defines a set of properties (their values and > behaviour) that will be added to an arguments object. Possible > properties beyond those specified are not covered at all. > >> Chrome fills that in, > > Chrome satisfies the requirements of the specification, in that it adds > the properties of the arguments object that are specified, and gives > then the correct values and behaviour. > >> but colors outside the lines a bit. > > Only in the sense that it does things beyond what is specified that are > neither required nor forbidden. > >> In doing that, it is going against what I read as the >> intent of the spec, > > You shouldn't try to read intent in the spec, the result will be > subjective and personal. Read the words in the spec. > >> which is to describe precisely when properties are added >> to arguments object. > > If that were the intent it would have been trivial to write the wording > that would make it mandatory. The absence of those words is significant. > >> 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. > > (I assume that this means that you have abandoned the idea that section > 10.1.8 contradicts the behavior exhibited by Chrome. i.e. your bug > report is incorrect in its assertion that it does.) > Either Object instances can have additional properties or they cannot. The section above says they cannot. The Arguments object is an Object instance and Object instances have no additional properties. It can be expected that arguments object has no additional properties except for under the specific circumstances stated in that section. > That section is best considered in comparison with similar section on > the properties of instances of other types, such as:- > > | 15.3.5 Properties of Function Instances The arguments object is not a function. [snip] > > No, an arguments object may have properties beyond those explicitly > specified. > Not if it is an Object instance. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Richard Cornford on 25 Feb 2010 13:40
On Feb 25, 5:35 pm, Garrett Smith wrote: > Richard Cornford wrote: >> Garrett Smith wrote: >>> Richard Cornford wrote: >>>> On Feb 24, 12:56 pm, Dmitry A. Soshnikov wrote: >>>>> On Feb 24, 2:43 pm, Richard Cornford wrote: >> <snip> >>>>> 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. > >> ECMA 262 specifies its own interpretation? > >>> What Chrome does is not explicitly mentioned and so is >>> not fully accommodated. > >> The conformance section requires that the things that are mentioned >> do happen. Anything that is not mentioned is not constrained or >> forbidden by the specification. Indeed, the third paragraph of the >> conformance section implies that anything that is not mentioned is >> explicitly allowed. > > Ah, no. The conformance section does not imply that "anything that > is not mentioned is explicitly allowed." > > That conformance section: > >| ..."A conforming implementation of ECMAScript is permitted to >| provide additional types, values, objects, properties, and >| functions beyond those described in this specification." > > I see a list of "types, values, objects, properties, and functions". > Not "anything". Don't forget the additional syntax allowed by the last paragraph of the conformance section. Once you are allowing additional types, values, objects, properties, functions and syntax what are you including in your 'anything' that is not allowed? > A conforming implementation that features existing built-in > Object, Such as - Object.prototype -? > is not permitted to provide additional properties to that > Object. AIQB: Yes they are. That is precisely what they are allowed to do, and very frequently do do. Object.prototype certainly is a built-in object, and it is pretty normal for it to have properties beyond those mentioned in ECMA 262. <snip> >>> 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. > >> (I assume that this means that you have abandoned the idea that >> section 10.1.8 contradicts the behavior exhibited by Chrome. >> i.e. your bug report is incorrect in its assertion that it does.) > > Either Object instances can have additional properties or they > cannot. They can. > The section above says they cannot. No, it says that, as specified in ECMA 262, they don't have any "special properties". > The Arguments object is an Object instance The arguments object starts off as an Object instance, it is then modified. > and Object instances have no additional properties. Even if I did accept that Object instances can have no properties beyond those listed in ECMA 262 3rd Ed., once they have been modified then their original state is no longer significant. > It can be expected that arguments object has no additional > properties except for under the specific circumstances stated > in that section. But it should not be expected. The stage of modifying an Object instance into an arguments object is precisely the sort of stage at which additional properties beyond those specified could be added. >> That section is best considered in comparison with similar section >> on the properties of instances of other types, such as:- > >> | 15.3.5 Properties of Function Instances > > The arguments object is not a function. No, but if a "Properties of ... Instances" section exists for all the equivalent types it should not be surprising if some of them just state that there is nothing to declare in such a section, while others, such as in the case of Function instances, list special properties of the instances. The absence of a list in such a context should not be taken as restrictive. If the spec wanted to say that Object instances could not have properties beyond those specified then it would simply have to say that they must not have such properties. It is the absence of such a restriction that means there is no restriction. And Function instances often have properties beyond those listed in section 15.3.4, such as a - name - property. This is exactly the sort of addition that the conformance section does allow. > [snip] >> No, an arguments object may have properties beyond those >> explicitly specified. > > Not if it is an Object instance. Yes if it is an Object instance, and yes if it was an Object instance that has been modified (the latter being the case here). Richard. |