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