Re: More string indexing semantics issues
2008/6/24 Allen Wirfs-Brock [EMAIL PROTECTED]:
Assuming the string index semantics I defined in my previous message, what
should the effect of setting a numeric property on a string whose property
name is a valid character position into the string?
For example:
var s = new String(abc)
s[1]; /* not valid in ES3, should yield b under extended semantics*/
s[1] = x; /* valid in ES3, but has nothing to do with the string
value */
s[1];/* both in ES3 and with extended semantics would yield x
Should the assignment, s[1] = x, still be valid in the present if we
support string indexing?
Argument for allowing: It's backwards compatible. There may be existing
ES3 programs that depend upon it.
Argument for disallowing: Allowing characters of a string to be accessed
using property access syntax makes the string elements appear as if they are
actually properties. There appears to be a joining of s[1] and
s.charAt[1}.
Since the value of a string is immutable, any property that is joined to a
an element of a string value should be a read-only property.
My inclination would be to disallow, but preserving existing code is one of
our top priorities. What do the existing implementation that support indexed
access to string elements do? If some of them disallow defining such
properties then there is probably enough existing divergence that the
compatibility issue doesn't really apply.
Webkit seems to have implemented a specialized [[Put]] for strings.
When the property is numeric, the property setting fails silently.
This can be observed by an example:-
javascript:(function(){var a = new String(Alan); a[0] = E;
alert(a[0]); })();
FF2: E
Sf3: A
OP9: E
IE7: E
It seems to me that Webkit's behavior is a bug.
This is something that I blogged about last year.
http://dhtmlkitchen.com/?category=/JavaScript/date=2007/10/21/entry=Iteration-Enumeration-Primitives-and-Objects#magic-string-source
Second issue:
I defined string index property access in such a way that such properties
appear to be non-enumerable. Is this reasonable? It's inconsistent with
arrays. However, saying that they are enumerable implies that for-in should
iterate over string element indexes which it now doesn't do. Also what
about meta operations like Object.prototype.hasOwnProperty? My current
semantics would cause it report true for string element indexes. Is this
reasonable? It's another set of incompatibilities.
It seems that nobody should be using a for in loop on a String or SV.
String.prototype.trim = ...
Would be an obvious reason. Using hasOwnProperty might be a
consideration, but why would anyone want to?
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On 25/06/2008, liorean [EMAIL PROTECTED] wrote: 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. A distinction I was going to make there fell away when I rewrote an awkward formulation... s/String object to deal with/String object that you haven't explicitly created using new String to deal with/ -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On Wed, Jun 25, 2008 at 1:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jun 25, 2008, at 1:33 PM, Garrett Smith wrote:
On Wed, Jun 25, 2008 at 1:25 AM, Maciej Stachowiak [EMAIL PROTECTED] 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
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On Jun 25, 2008, at 4:00 PM, Garrett Smith wrote:
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?
Yes.
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?
I just tried this in Safari 3.1 and Safari alerted true. The same
happens in WebKit trunk. If it alerted false I would say that is a bug.
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.
You could model it in many ways. I have not looked at Mozilla's or
Opera's actual implementations. What I am saying is that Safari/WebKit
tries to publicly present the logical model that these are ReadOnly
DontDelete properties. How it's actually implemented isn't really
relevant. In WebKit's implementation we implement all sorts of JS
properties internally in ways other than putting them in the generic
object property map.
It is true that in spec-speak you could define it as special [[Get]]
and [[Put]] behavior (and other operations like [[Delete]] and
[[HasOwnProperty]]) instead of special properties.
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.
What I am talking about above is the equivalent of the spec's [[Get]],
not [[Put]]. The specialization I describe is for performance, and
behaviorally transparent. However, our JavaScript implementation
doesn't have things that correspond exactly to the spec's [[Get]] and
[[Put]] formalisms.
Regards,
Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On Jun 25, 2008, at 2:33 PM, Garrett Smith wrote: On Wed, Jun 25, 2008 at 1:52 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I have not seen any reports of such problems. If it were common to put random numeric properties on String objects, I expect we would have had a bug report by now. Why? What I meant is this: 1) When Safari/WebKit/JavaScriptCore diverges from other browsers in JavaScript behavior, in ways that Web content depends on, we have historically gotten bug reports even when the issue is very obscure. See my earlier comments about things like function declarations in statement position for examples. 2) We have not gotten bug reports that involve a site breaking because it set a low numeric property on a String object, and did not get the expected value back. At least, none have been found to have this as the cause. In other words, we have not seen cases like this: var s = new String(abc); s[0] = expected; if (s[0] != expected) alert(EPIC FAIL); 3) Therefore, I think it is unlikely that a lot of public Web content depends on being able to do this. If this were at all common, odds are that we would have heard about it by now. As Brendan suggests, deploying the behavior in beta versions of other browsers would give us more data points. Do you are there many Webkit only applications? Do these applications take advantage of string indexing via property access? I do not think the existence of WebKit-only applications is relevant. There are in fact a fair number (for example Dashboard widgets and iPhone-specific Web apps), but they do not tell us anything about whether public Web content at large depends on the behavior of allowing any numeric property of a String object to be successfully assigned. (I do not think any of this content depends on the WebKit behavior either). Regards, Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
More string indexing semantics issues
Assuming the string index semantics I defined in my previous message, what should the effect of setting a numeric property on a string whose property name is a valid character position into the string? For example: var s = new String(abc) s[1]; /* not valid in ES3, should yield b under extended semantics*/ s[1] = x; /* valid in ES3, but has nothing to do with the string value */ s[1];/* both in ES3 and with extended semantics would yield x Should the assignment, s[1] = x, still be valid in the present if we support string indexing? Argument for allowing: It's backwards compatible. There may be existing ES3 programs that depend upon it. Argument for disallowing: Allowing characters of a string to be accessed using property access syntax makes the string elements appear as if they are actually properties. There appears to be a joining of s[1] and s.charAt[1}. Since the value of a string is immutable, any property that is joined to a an element of a string value should be a read-only property. My inclination would be to disallow, but preserving existing code is one of our top priorities. What do the existing implementation that support indexed access to string elements do? If some of them disallow defining such properties then there is probably enough existing divergence that the compatibility issue doesn't really apply. Second issue: I defined string index property access in such a way that such properties appear to be non-enumerable. Is this reasonable? It's inconsistent with arrays. However, saying that they are enumerable implies that for-in should iterate over string element indexes which it now doesn't do. Also what about meta operations like Object.prototype.hasOwnProperty? My current semantics would cause it report true for string element indexes. Is this reasonable? It's another set of incompatibilities. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
