More string indexing semantics issues

[Mike Shaver]

On Wed, Jun 25, 2008 at 3:15 PM, liorean <liorean at gmail.com> wrote:
> On 25/06/2008, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:
>>  I think in this case I have to agree with Maciej...Webkit appears to be doing the "right thing" by making a string appear to consistently have a set of numerically named readonly properties that exactly correspond to the elements of the string value.
>
> Well, the way I think about String objects and strings:
> - A string can't have properties of it's own at all, i.e. can be
> thought of as having a noop setter and a custom getter for indices and
> length. Any property not found by the getter should get delegated to
> String.prototype.
> - A String object is just a normal object delegating to a string.
> (Could probably reuse the [[Prototype]] internal property if
> implemented that way...) Thus, any properties set are placed on the
> wrapper object and would as a result of that shadow the getter and
> setter on the string.

That's not how they work today, though, at least as far as the .length
property goes:

js> s = new String("foo")
foo
js> s.length
3
js> s.length = 5
5
js> s.length
3
js>

And of course it has to delegate to an object that has all the right
methods on it.

Are "numerically-named" properties >= length settable?

> Neither the direct access of characters in the string by indiced
> property lookup nor the use of String objects is common, so the
> overlap is in all probability diminutive.

Direct use of characters is pretty common, I think, but you sound like
you are stating fact rather than opinion, so I'm prepared to be swayed
by your data.  String objects are very commonly created[*], by people
calling methods or accessing properties like .length on string
primitives.

[*] we optimize the object creation away there for built-ins, and I
believe that WebKit is about to do the same thing, but that doesn't --
can't! -- affect the semantics of object creation, and the
relationship to String.prototype.

Mike