[Harmony Proxies] Proposal: Property fixing
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.
>> 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
) 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
Of course, this would be just for spec purposes and implementations
would have all liberty to implement differently than what the spec says.
 WeakMaps aren't necessary since we're dealing with a spec not an
More information about the es-discuss