Proposed ES4 draft 1

[Lars Hansen]

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of liorean
> Sent: 17. mai 2008 03:07
> To: es4-discuss at mozilla.org
> 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