More string indexing semantics issues

Mike Shaver mike.shaver at
Wed Jun 25 12:47:14 PDT 2008

On Wed, Jun 25, 2008 at 3:15 PM, liorean <liorean at> wrote:
> On 25/06/2008, Allen Wirfs-Brock <Allen.Wirfs-Brock at> 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")
js> s.length
js> s.length = 5
js> s.length

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

[*] 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.


More information about the Es4-discuss mailing list