More string indexing semantics issues

Garrett Smith dhtmlkitchen at gmail.com
Wed Jun 25 16:00:41 PDT 2008


On Wed, Jun 25, 2008 at 1:49 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 25, 2008, at 1:33 PM, Garrett Smith wrote:
>
>> On Wed, Jun 25, 2008 at 1:25 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> On Jun 24, 2008, at 11:45 PM, Garrett Smith wrote:
>>>
>

(putting this back on the list; it contains nothing personal).

> None of this explains why you think the WebKit behavior is a bug.

It seems like a bug because it prevents property assignment to String
objects. I also said something along the lines of: "I'm not overly
concerned with that."

>You seem
> to be hung up on "specialized [[Put]]" but I don't understand what that has
> to do with anything.

I was trying to answer the OP (Allen's) question: "Should the
assignment, s[1] = "x", still be valid in the present if we support
string indexing?" Which is a natural way of asking about [[Put]]/
[[CanPut]].

ISTM the heart of the problem is to allow special [[Get]] access to
characters in the String; that the problem itself has nothing to do
with [[Put]]. However,  Allen asked a question with real world
implementation. Webkit's behavior, to me, appeared to have implemented
a modified [[Put]]. I'm trying to understand what Webkit does and it
seems related to the Allen's question:

"Should the assignment, s[1] = "x", still be valid in the present if
we support string indexing?"

Where what webkit does has different results of what mozilla and Opera do.

> In spec terms, WebKit's behavior can be explained in
> terms of strings having additional DontDelete ReadOnly properties.

Let me get this straight:

Webkit's behavior can be explained in terms of String objects having
additional properties with numeric names and the attributes
{DontDelete ReadOnly}

Is that what you meant?

> The
> Mozilla behavior can be explained as strings having those same additional
> properties, but they are not ReadOnly. In both cases, index properties past
> the last character do not exist ahead of time.
>

My observations indicate otherwise. Webkit does not appear to create
additional properties to String objects.

javascript:alert(Object("foo").hasOwnProperty(0));

FF2 - true
Sf3 - false
Op9 - false

Where does the "0" property exist, Maciej? Is this bug related to
hasOwnProperty?

It appears to me that Mozilla and Opera and Webkit all implement a
specialized [[Get]], where Opera and Mozilla do:

1) Look for property P on String object.
2) Look for String instance charAt( P )
3) Look in String prototype.

Webkit does:-
1) Look for String instance charAt( P )
2) Call the[[Get]] method on S with argument P.

javascript:var f = Object("1234567");void(String.prototype[0] = "0");
void(f[0] = "8"); alert(f[0]);

"8" in Opera9 and FF2.
"0" in Saf3.

In Opera, the object doesn't have numeric properties, and only appears
to have special [[Get]]:-
javascript:alert("0" in Object("foo"));
javascript:alert(Object("foo")[0]);

Op9 - false and "f"
FF2 - true and "f"

Mozilla has the properties on the object and Opera doesn't.

(this explains why - Object("foo").hasOwnProperty(0) - is false in Opera.

> The reason for the way WebKit does things, for what it's worth, is because
> index properties of the string are checked first before normal properties
> (because they can't be overwritten), so "abc"[1] can be as fast as an array
> access instead of going at the speed of normal property access.
>

So the [[Put]] method on a String instance is different in Webkit.

Garrett

> Regards,
> Maciej
>



More information about the Es4-discuss mailing list