More string indexing semantics issues
liorean at gmail.com
Wed Jun 25 12:15:26 PDT 2008
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.
> In a clean-slate world, I think that should be the end of the discussion. However, we have backwards compatibility issues to consider. By the book ES3 allows numerically named properties to be added to String objects that are unrelated to the string value, and 2 out of the 3 widely used browser-based implementations that support property style access to the string value also allow such properties to be added. Only Webkit deviates from this. Right or wrong, from a pure compatibility perspective preserving that capability would be important **if we think that there is any significant usage of it**.
I expect almost all usage of "new String" to be from people who either
stage yet. And maybe one or two library writers who are too clever for
their own good...
> The fact that Safari seems to be getting away with its implementation without being badgered into conformance suggests that there probably isn't any such significant usage.
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.
David "liorean" Andersson
More information about the Es4-discuss