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?
For example:
var s = new String("abc")
s[1]; /* not valid in ES3, should yield "b" under extended semantics*/
s[1] = "x"; /* valid in ES3, but has nothing to do with the string value
*/
s[1]; /* both in ES3 and with extended semantics would yield "x"
Should the assignment, s[1] = "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[1] 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.
Second issue:
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.
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
