2008/5/17 Lars Hansen <[EMAIL PROTECTED]>: > 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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
