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/
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
