Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
2012/12/19 David Bruant <bruan...@gmail.com <mailto:bruan...@gmail.com>>
Le 19/12/2012 17:34, Brandon Benvie a écrit :
So the remaining situations in which it's difficult are in
the parent frame when you want to do this one of the handful
of properties that have this treatment.
An option that might have uses in other places as well is a
kind of primitive version of call, bind, and apply that have
the null prototype, frozen treatment. They could be
singletons over the entire runtime, across realms, and be
attached to any function in any realm (including these
accessors) without leaking anything.
I think that was what Brendan called "null realm". It has the
problem that if someone adds new things to Function.prototype or
Object.prototype, your "null realm" getters/setters wouldn't
benefit from it.
Is that really a problem though?
I don't know. I was just repeating the main argument against this idea.
Historically, the ECMAScript representation of browser APIs was probably
the least interoperable part of the web platform and certainly still is.
Open http://davidbruant.github.com/ObjectViz/ and click anywhere, it
should visualize a click event object. The result is *very* different in
the latest Chrome, Firefox, Opera and IE (I haven't tested Safari but I
assume it's the same than Chrome). There are good reasons for this (lack
of spec initially then software architecture issues).
Web devs have written at length about the fact that extending the DOM
was a bad idea [1].
But let's project ourselves in a world of WebIDL compliant browsers and
ES5+symbols.
Suddenly, extending the ECMAScript environment is safe (collision-free)
with unique symbols and extending the DOM is both safe and reliable
(thanks to WebIDL-compliance).
Will special-casing WindowProxy [Unforgeable] getters/setters undermine
the possibilities of this world? I cannot tell. I'm too used to the
current world where extending the language is socially unacceptable.
I'm not worried about backward-compat (because as you and Brandon said,
it's not a problem). I'm rather worried about potential forward-compat
issues.
configurable:true seems to be more future-friendly.
I think I'm leaning towards non-configurable accessors with
deep-frozen (null-realm) getter/setter functions.
Brandon's point about the fact that it really is the matter of a few
properties made me reconsider my position. I'm between deeply-frozen and
configurable:true and can't make up my mind :-s
David
[1] http://perfectionkills.com/whats-wrong-with-extending-the-dom/
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
