More string indexing semantics issues
Allen.Wirfs-Brock at microsoft.com
Tue Jun 24 22:47:18 PDT 2008
Assuming the string index semantics I defined in my previous message, what should the effect of setting a numeric property on a string whose property name is a valid character position into the string?
var s = new String("abc")
s; /* not valid in ES3, should yield "b" under extended semantics*/
s = "x"; /* valid in ES3, but has nothing to do with the string value */
s; /* both in ES3 and with extended semantics would yield "x"
Should the assignment, s = "x", still be valid in the present if we support string indexing?
Argument for allowing: It's backwards compatible. There may be existing ES3 programs that depend upon it.
Argument for disallowing: Allowing characters of a string to be accessed using property access syntax makes the string elements appear as if they are actually properties. There appears to be a "joining" of s and s.charAt[1}.
Since the value of a string is immutable, any property that is "joined" to a an element of a string value should be a read-only property.
My inclination would be to disallow, but preserving existing code is one of our top priorities. What do the existing implementation that support indexed access to string elements do? If some of them disallow defining such properties then there is probably enough existing divergence that the compatibility issue doesn't really apply.
I defined string index property access in such a way that such properties appear to be non-enumerable. Is this reasonable? It's inconsistent with arrays. However, saying that they are enumerable implies that for-in should iterate over string element indexes which it now doesn't do. Also what about meta operations like Object.prototype.hasOwnProperty? My current semantics would cause it report true for string element indexes. Is this reasonable? It's another set of incompatibilities.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss