David Bruant wrote:
Thanks for the notes and complements :-)
Le 24/05/2012 04:43, Brendan Eich a écrit :
Rick Waldron wrote:
Triangle
Is capable of giving up private names
If people have __proto__ they will not use <|.
I don't know who are "people" but I'm not one of them. <| offered some
nice sugar with regard to constructors. Just sugar but it was convenient.
The argument Rick summarized by "If people have __proto__ they will not
use <|" was a bit more nuanced.
If people have to write code for pre-ES6 and ES6 browsers, then *even if
ES6 has <| support*, because __proto__ is coming to ECMA-262 (either in
Annex B as normative optional, or in the main normative-mandatory spec),
and therefore Microsoft will finally implement __proto__, any people who
are writing JS for old and new browsers -- particularly mobile browsers
where IE has too little share to count today -- will use __proto__ only.
New syntax requires a transpiler at least. That's too high a tax if
there's already a de-facto standard API such as __proto__ that
developers can use that works on older and new browsers in their
addressable target markets.
Aside from this point, a separate point: <| is sugar but it looks bad
(in my font, right now, in fact) in too many renderings. So even
ignoring the point above, <| faced serious grawlix and
looks-ugly-in-too-many-fonts objections.
MM:
- From a security perspective, I'd like to move __proto__ out of
annex B and into normative body
BE:
- If MS puts __proto__ in IE, then it becomes defacto standard and
we might as well put it in the standard.
1. __proto__
2. grawlix
Resolution: Indefinite postpone\
I.e., we defer/cancel triangle and go with normative mandatory
__proto__. W00t! Kidding, mostly, but I perpetrated it, it is in all
browsers but IE, and IE feels the heat on mobile (thank you Thomas
Fuchs!). So __proto__ is the winner already, we're just trying to
forestall the inevitable.
It seems that "delete Object.prototype.__proto__" would be the first
line I'd write if I wanted to prevent __proto__ from being harmful.
However, since <| is out, after doing the delete, the use cases it was
intended for (array subclassing is zepto.js' use case, right?
Not just array -- DOM too.
) cannot be achieved anymore.
So don't delete __proto__ :-P.
Really, you can't have it both ways. If you want Zepto, you are not
running SES code. Let's see if someone can "cajole" Zepto and then talk.
I think we can only recover is if it's possible to extract a proto
setter before the delete. I haven't seen a resolution on the
__proto__-related notes, but considering that <| is out, can it be
consider to just do a setter?
No, we agreed that adds a new hazard not present in almost all browsers
today or over the last 12 years: an extractable setter. We agreed to
spec __proto__ as a magic data property.
Once we're at it, for the sake of completeness there is probably no
harm in adding a Reflect.setPrototype at this point, is there?
There is, just as there's a cost to Object.setPrototypeOf (the obvious
place to put it to match Object.getPrototypeOf from ES5). Mark pointed
out that he'd have to delete that static method too, and from every
frame that might run SES code. But when mashing up SES and non-SES code,
it would be better not to break the non-SES code by such deletion.
Having only the SES environment's Object.prototype.__proto__ to delete
is better.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
