Hi,
If __proto__ is getting standardized, I propose we adapt proxies to be able
to trap getPrototypeOf.
Why?
- with __proto__, stable prototypes are no longer an invariant. It's
awkward to make proxies go out of their way to maintain it still.
- it's much more consistent with all the other Object.* methods:
Object.keys(proxy) => calls keys trap
Object.getPrototypeOf(proxy) => calls getPrototypeOf trap
- it makes membranes much simpler, because they can now do:
getPrototypeOf: function(target) {
return wrap(Object.getPrototypeOf(target));
}
This saves the extra object allocation to create a dummy target with a
wrapped prototype.
To be consistent with the other traps, if we buy into a getPrototypeOf
trap, we should add a getPrototypeOf method in the "reflect" module as well
(basically an alias for Object.getPrototypeOf).
Your thoughts?
Cheers,
Tom
2012/5/24 Brendan Eich <[email protected]>
> 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<https://mail.mozilla.org/listinfo/es-discuss>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
