More string indexing semantics issues

[Brendan Eich]

On Jun 25, 2008, at 9:37 AM, Allen Wirfs-Brock 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.

IIRC, we intentionally allowed overriding indexed properties to be  
set on String objects, for backward compatibility.

So, we chickened out. Minority share browsers facing a rare use-case  
conflicting with an extension sometimes do that. It's hard to know  
when getting away with something in such a setting means you can  
continue to get away clean, never mind whether a new version of the  
standard should codify the minority behavior.


> 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**.  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.

Probably. But we don't know enough.


> So, unless someone has some evidence that it is going to "break the  
> web" I'm going to leave by ES3.1 specification the way it currently  
> is written, which implements the observed behavior of Webkit.

This isn't the only way to proceed. Changing a pre-release, but  
widely used, Firefox build to match Safari would help. Changing IE  
beta-next as well would help even more. None of this would be  
decisive, but it would trump any assertions we can make today.

Again I am concerned with making an ES3.1 with zero implementations  
before the standard is finalized.

/be