More string indexing semantics issues
mike.shaver at gmail.com
Wed Jun 25 12:47:14 PDT 2008
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
> - 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
js> s = new String("foo")
js> s.length = 5
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