> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of liorean > Sent: 17. mai 2008 03:07 > To: [email protected] > Subject: Re: Proposed ES4 draft 1 > > > In core-language.pdf, "1.3.1 Property Binding Map", a paragraph reads: > "A property binding map stores the order in which properties > are added to the map. A property's position in this order is > unchanged when the property is replaced. This order is used > by property enumeration (see the chapter on Statements)." > > I just wish you make clear one detail here: Does removing and > adding a property with the same name change its enumeration > order, or is that equivalent to a replacement? I think it > probably should remove it from the enumeration order and > insert it at the end.
I agree, and I think the spec needs to be clear on this. > In core-language.pdf, "1.4.5 String Values", you allow both > ES3 compatible 16-bit UCS-2 code units and 32-bit Unicode > code points (and, I would assume, 21-bit code units which > would behave exactly as if they were UTF-32 code units). > If an implementation is UTF-8 under the hood but leaves the > programmer-visible indexed access per either one of those > models (with notably worse algorithmical complexity for > random access but not for serial access), is that okay per the spec? If it's under the hood it's out of the spec's jurisdiction, but it's possible the spec could be clearer about that. We'll see. > In core-language.pdf, "2.1 Catch-All Methods", the default > behaviour of accessing the value from a dynamic property in > the object's property map is mentioned. Is there a way for > non-default catch-alls to do this, too? (Maybe they only want > to treat a special subset of property names differently, not > all names...) There is not. > In core-language.pdf, "2.3 Reading a property value" the last > fixme reads: > "FIXME We need to specify whether the bound method is cached > or not, ie, whether, given that o.m is a method, (o.m === o.m)." > > Whether o.m is a method or not shouldn't change anything, should it? > As long as it's just named and not called it's the same > object. If there's a setter or getter for that particular > name or a catch-all, now, that's where this issue arises. You're assuming the conclusion. The reason this is an interesting question is that good implementations will not allocate function objects for methods until they need to (at that point performing an implicit 'bind' operation too, of course), and the question is whether implementations will be required to cache these objects when they do create them. I think the sane thing to do is to require lazily created objects to be cached; it simplifies the language and the spec -- objects appear to "have" properties that are bound methods -- even if it adds an additional burden to some implementations. --lars _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
