More string indexing semantics issues

[Garrett Smith]

2008/6/24 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>:
> 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.
>
>

Webkit seems to have implemented a specialized [[Put]] for strings.
When the property is numeric, the property setting fails silently.
This can be observed by an example:-

javascript:(function(){var a = new String("Alan"); a[0] = "E";
alert(a[0]); })();

FF2: "E"
Sf3: "A"
OP9: "E"
IE7: "E"

It seems to me that Webkit's behavior is a bug.

This is something that I blogged about last year.
http://dhtmlkitchen.com/?category=/JavaScript/&date=2007/10/21/&entry=Iteration-Enumeration-Primitives-and-Objects#magic-string-source

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

It seems that nobody should be using a for in loop on a String or SV.

String.prototype.trim = ...

Would be an obvious reason. Using hasOwnProperty might be a
consideration, but why would anyone want to?

Garrett