Proposed ES4 draft 1

[liorean]

2008/5/17 Lars Hansen <lhansen at adobe.com>:
> Enclosed is a quite incomplete first draft of the specification for the
> Proposed ECMAScript 4th Edition.  This draft is comprised of a short
> introduction, the surface grammar, and a description of the core
> semantics -- values, storage, types, names, scopes, and name resolution.
> More will follow as it is ready, probably on a (more or less) bimonthly
> schedule.  See the introduction for a general discussion.

In core-language.pdf, section "1.2 Null", the note reads
"NOTE While the null and undefined values have similar meanings, they
have different conventions of use. The null value is intended to
indicate a missing object value, while the undefined value is intended
to indicate a missing property on an existing object value. These
indeded uses are conventions, and are not enforced by the language
semantics."

Besides the obvious spelling error,  I think your terminology of
"missing object value" and "indicating missing property on an existing
object" are actually more confusing than helping. I would characterise
null as being the "invalid object value"; i.e. "the object that is not
an object", in analogy with NaN being "a number that is not a number".
(Or s/the (object|number)/the value/ if you prefer that, since the
spec specifically mentions null not being an object.) The value
undefined on the other hand has several distinct meanings: It either
represents a storage slot (variable/argument/object property) that has
not been assigned a value, it represents a storage slot not existing
at all, or it represents a storage slot explicitly being set to
undefined by the programmer. Three entirely different things. I like
to explain that as undefined being the "value that is not a value" in
analogy to how I explain null and NaN. Not saying I think the spec
should say just those things in particular, just that I think your
characterisation of them is a bit dissonant with their nature,
especially undefined being much broader in meaning than your
definition of it.



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. Also, knowing a bit
about Opera's planned behaviour on this for Futhark , I'd like the
correct behaviour for enumeration after a delete well defined.


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?


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...)


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.
-- 
David "liorean" Andersson