[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Fri May 13 05:18:12 PDT 2011


Le 13/05/2011 04:09, Cameron McCormack a écrit :
> Allen Wirfs-Brock:
>> I'm still hopeful that I can eliminate [[Class]] entirely from the
>> ES.next specification.
>>
>> What is WebIDL really trying to accomplish when it specifies class
>> values. Parameterizing toString. Trademarking objects? Something else.
>> All the use cases I have seen for [[class]] an be accomplished some
>> other way rather than by over-loading this specification device with
>> additional meanings.
> All it is trying to accomplish is making
> Object.prototype.toString.call(object) return the kinds of values that
> websites expect.  Websites are doing that to check the type of the
> object they’ve got, yes.
>
>> See
>> http://wiki.ecmascript.org/doku.php?id=strawman:es5_internal_nominal_typing
>> for a sketch of what I have in mind
> Being able to parameterise Object.prototype.toString is all that’d be
> needed.  I suppose that can’t be done just with a self-contained Proxies
> spec, but requires changes to the Object.prototype.toString definition.
Yes and no. In https://gist.github.com/970223 , I indeed redefine 
Object.prototype.toString, but this change is transparent and 
un-noticeable from user code (since it only affects objects for 
constructor the DOM environment controls). From the way I see it, a web 
browser ES environment works like this (of course, this is a naive view):
1) Initialize a fresh ES-compliant environment (built-in defined in the 
spec (including global object))
2) Initialize the DOM environment (all constructors (Node, Element...) 
and basic objects (window (global object extension), document...))
3) Start parsing HTML (appending DOM elements along the way) and run 
scripts as they arrive (what I call "user code").

So if phase 2 changes any built-in in a way that is not noticeable from 
user code, I don't think it's a problem. In my code, the only way I see 
that some code could understand that Object.prototype.toString has been 
changed is by comparing object identities. But since user code only 
occur after phase 2 is completed, it cannot get the ES built-in 
Object.prototype.toString identity to compare afterward.

So, my example changes Object.prototype.toString definition strictly 
speaking, but not as far as web authors are concerned.
Given that my 3 phases model is correct, in my opinion, WebIDL, in its 
effort to define the DOM in terms of ECMAScript 5 (+ Harmony proxies 
[1]) can take all liberty to make changes to the definition of built-ins 
as long as the ES environment looks fresh after phase 2. This would 
allow duck-typing when necessary. This would allow to define a couple of 
consistently implemented non-standard methods which belong in web 
browsers more than ECMAScript (see five last String.prototype.* methods 
in [2]).
Of course, this would be just for spec purposes and implementations 
would have all liberty to implement differently than what the spec says.

David

[1] WeakMaps aren't necessary since we're dealing with a spec not an 
actual implementation
[2] http://kangax.github.com/es5-compat-table/non-standard/


More information about the es-discuss mailing list