More string indexing semantics issues

[liorean]

> On Wed, Jun 25, 2008 at 3:15 PM, liorean <liorean at gmail.com> wrote:
>  > 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.

Yes, I had thought of that too, but then I had already pressed the
send button...

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

In saf3.1.1, ff3.0 and op9.50 they are, yes.

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

I'm not stating that from any collected data, no. It was purely based
on three things:
- The only scripts I have seen using it both happen to be made by
advanced coders and happen to not have IE in their target audience for
some reason (extension, widget, greasemonkey script, userjs,
bookmarklet for some specific browser etc.).
- IE does not support it so logically it wouldn't be present in very
much code on the web.
- I can't recall ever seeing anybody on a forum or a mailing list
actually having a problem related to use of index lookup directly on
strings. And I'm sure that if it was common outside the developers
that do not have IE in their target audience at all, then there would
be people having trouble with it.

Also, while String objects are created as temporaries when looking up
a property on a string, how many of those properties or methods
actually return a String object? The only situation I can think of off
the top of my head where you're going to actually have a String object
to deal with in ES3 is if you're extending the String.prototype object
with new methods.

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

Yes, I know my way of looking at it is not quite what is happening.
But for a script writer, it's a good enough model of thought about the
relation between the primitive and compound objects.
-- 
David "liorean" Andersson