On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads, or else
people read and think less of the spec on that account.
The fewer read about it the better, no? :)
Why would people think less about the spec?
I
Le 28/12/2012 10:29, Andreas Rossberg a écrit :
On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads,
or else people read and think less of the spec on that account.
The fewer
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Changing---Prototype---tp34830218p34838926.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It would indicate that it's part of the standard, but is
a scar from history rather than a legit feature.
An intro would explain what this is all about.
It
On 28 December 2012 11:51, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto standards?
It would indicate that it's part of the standard, but is a scar from
history rather than a
Le 28/12/2012 12:51, Andreas Rossberg a écrit :
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in all browsers, __defineGetter__ is not.
--
Andreas Rossberg wrote:
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in
On 28 December 2012 13:34, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
That's a good point, actually. I, for one, do not understand the
criteria by which we chose to include __proto__ but not __defineGetter__
and friends.
__defineGetter__ and friends have sane
On Dec 28, 2012, at 7:36, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com
wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to
What herby said is the reason. There's no compatibility burden for either
those or __proto__ because no version of IE implements either. However
__proto__ still has no alternative, while the accessor functions are fully
replaced by ES5 features.
The only code you'll find in the wild that relies
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a sufficiently minor player, that some cross-mobile-platform code
assumes mutable
On 28 December 2012 19:55, Mark S. Miller erig...@google.com wrote:
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a
On Dec 28, 2012, at 11:48 AM, Andreas Rossberg rossb...@google.com wrote:
All understood, but what's the difference to __defineGetter__?
That MS does not appear to feel pressure to implement __defineGetter__ but it
does feel pressure to implement __proto__.
Dave
Andreas Rossberg wrote:
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It
On Friday, December 28, 2012, David Bruant wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto standards?
It would indicate that it's part of the standard, but is a scar from
history rather than a legit feature.
Le 27/12/2012 06:40, David Herman a écrit :
We've given up on the (non-existent) invariant that [[Prototype]] is
immutable. That doesn't mean we should set caution to the wind and
specify standard libraries that mutate [[Prototype]] links whenever it
happens to solve some problem.
As you'll
On 27 December 2012 06:38, David Herman dher...@mozilla.com wrote:
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
It seems ES6 has __proto__ which also allows modifying [[Prototype]]
so presumably this is nothing particularly bad, although it is very
ugly :-(
It
On Thu, Dec 27, 2012 at 6:38 AM, David Herman dher...@mozilla.com wrote:
Thank for the heads up. I'll chat with bz to get more of the back story. This
is pretty effing awful. It may in fact be unavoidable but I'd like to make
sure I understand why people feel there's no alternative; otherwise
Andreas Rossberg wrote:
On 27 December 2012 06:38, David Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
It seems ES6 has __proto__ which also allows modifying [[Prototype]]
On 27 December 2012 18:25, Brendan Eich bren...@mozilla.com wrote:
That is, if having it at all, I'd still think it much wiser to ban it to
some Appendix.
What earthly good would that do?
Marketing and psychology (as I said, being important). It would send a
clear message that it is just
Andreas Rossberg wrote:
On 27 December 2012 18:25, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
That is, if having it at all, I'd still think it much wiser to
ban it to some Appendix.
What earthly good would that do?
Marketing and psychology (as I
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
I thought I'd give a heads up as over on www-...@w3.org we're
discussing two cases where we likely need to change the prototype
chain of objects: document.open() and methods that do the equivalent
of document.adoptNode()
On Dec 24, 2012, at 2:17 AM, David Bruant bruan...@gmail.com wrote:
The ability to change the [[Prototype]] of an object is orthogonal to the
__proto__ problem. If it's necessary for DOM objects to change the
[[Prototype]] for backward-compat or security reasons, it can do so, I guess.
I thought I'd give a heads up as over on www-...@w3.org we're
discussing two cases where we likely need to change the prototype
chain of objects: document.open() and methods that do the equivalent
of document.adoptNode() (including that method itself):
Le 24/12/2012 10:48, Anne van Kesteren a écrit :
I thought I'd give a heads up as over on www-...@w3.org we're
discussing two cases where we likely need to change the prototype
chain of objects: document.open() and methods that do the equivalent
of document.adoptNode() (including that method
With the problem at hand and the solution currently being proposed
(nodes changing of [[Prototype]] on adoptNode), it will remain possible
to observe objects changing of [[Prototype]] after a delete
Object.prototype.__proto__. I don't know to what extends it's a good or
a bad thing, but I
That doesn't seem to be a problem. Host objects may be losing most/all of
their magic but it's certainly reasonable that they have privileged access
to capabilities. I think it makes sense to frame deleting __proto__
as simply removing access to a capability from the user, but the capability
still
Le 24/12/2012 15:50, Brandon Benvie a écrit :
That doesn't seem to be a problem. Host objects may be losing most/all
of their magic but it's certainly reasonable that they have privileged
access to capabilities. I think it makes sense to frame deleting
__proto__ as simply removing access to a
31 matches
Mail list logo
