apologies, I've realized SES might want more something like this:
(function(getOwnPropertyDescriptor){
Object.defineProperty(
Object,
'getOwnPropertyDescriptor',
{
enumerable: false,
configurable: false,
writable: false,
value: function(object, property) {
var d = getOwnPropertyDescriptor(object, property);
if (d && property === '__proto__') {
d.set = function () {
throw new Error('nope');
};
}
}
}
);
}(Object.getOwnPropertyDescriptor));
as this is basically what's in V8 now (assuming d && property ===
'__proto__' can be true only with Object.prototype)
well, I am sure you all got the point about the possibility of replicating
or being completely free from this property
On Sun, Apr 21, 2013 at 2:11 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> agreed for consistency too, once deleted, the magic should disappear 100%
>
> reality will be that most devs won't delete it so I don't see concrete
> side effects out there.
>
> However, this is how I would spec it (or better, how I would drop the axe
> accepting a compromise for this property)
>
> Object.getOwnPropertyDescriptor(Object.prototype, '__proto__')
> must return
> {
> enumerable: false,
> configurable: true,
> get: function usableGetter(){},
> set: function usableSetter(){}
> }
>
> Being configurable anyone can decide to poison the setter, if necessary,
> or trap it and get read of the magic.
> It is not possible to have options if the setter is poisoned by default or
> not exposed at all.
> The magic can be preserved, if necessary, and reused.
>
> "First come first serve" as same rule exists today if somebody wants, for
> some reason,
> Object.freeze(global);
> or
> Object.freeze(Object.prototype);
> with all toString, etc consequences we know ... it worked 'till now,
> libraries can evolve and/or agree on the expected surrounding environment.
>
> Once deleted, the whole magic should disappear.
> var o = {__proto__:null};
>
> will be an instanceof Object with .hasOwnProperty('__proto__') true and
> .propertyIsEnumerable('__proto__') true and o.__proto__ === null
>
> In few words, once __proto__ has been deleted, that name means that's a
> property name and nothing else.
>
> I think this makes specs easy to define:
> if not there, everything as it is for everything else
>
> if there, define the property descriptor without adding any extra/special
> case on it
>
> This is the easiest way to go, this can make SES the same is today doing:
>
> Object.defineProperty(
> Object.prototype,
> '__proto__',
> {
> get: Object.getOwnPropertyDescriptor(
> Object.prototype,
> '__proto__'
> ).get,
> set: function () {
> throw new Error('you are not supposes to do this');
> }
> }
> );
>
> This will make possible to create e single entry point for the magic and
> monitor it:
>
> var set = Object.getOwnPropertyDescriptor(
> Object.prototype,
> '__proto__'
> ).set;
>
> delete Object.prototype.__proto__;
>
> This will make whoever wants to do anything with this magic able to do it
> and, accordingly, I believe a happy JavaScripter!
>
> My 2 cents
>
>
>
>
>
>
>
> On Sun, Apr 21, 2013 at 1:37 PM, Brendan Eich <bren...@mozilla.com> wrote:
>
>> Allen Wirfs-Brock wrote:
>>
>>> On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
>>> > You don't want that to affect object literals evaluated in the same
>>> realm after such a deletion. Why not?
>>>
>>> Why should it?
>>>
>>
>> ... because it did in ES5-conforming implementations that support
>> __proto__ as a de-facto standard *and* allow delete
>> Object.prototype.__proto__.
>>
>>
>> We already used the existence of {__proto__: whatever} got rid of<|
>>> as declarative syntax for defining an object literal with a [[Prototype]]
>>> other than object prototype. Making {__proto__: whatever} only work some
>>> of the times means it isn't a reliable declarative syntax.
>>>
>>
>> What?
>>
>> Mark insists on delete Object.prototype.__proto__ making the magic go
>> away. (Summoning Mark.)
>>
>> Triangle died for several reasons, and I'm surprised to hear it here.
>> Grinding an axe?
>>
>>
>> Why would we want to do that? There is arguably a good motivation
>>> wanting disable the ability to dynamically __proto__ modify arbitrary
>>> pare-existing objects. But what is the motifacation for doing that on newly
>>> created objects?
>>>
>>
>> I will tag Mark in here, but first make my own move:
>>
>> Answer: because the clear way to implement this in ES5-conforming
>> implementations that support __proto__ is to call [[Put]] not
>> [[DefineOwnProperty]] if the name of the property being initialized in the
>> object literal is '__proto__', and that's what engines implement.
>>
>> That makes a new de-facto standard, which you should not be wasting
>> energy trying to break!
>>
>>
>> SpiderMonkey at least goes out of its way to do [[Set]] (let's call it)
>>>> not [[DefineOwnProperty]] for 'o = {__proto__: 42}', so why wouldn't
>>>> [[Set]] create a fresh property, seeing nothing on Object.prototype named
>>>> '__proto__' with a setter to run?
>>>>
>>>
>>> Because the semantics that says you can't use [[DefineOwnProperty]] may
>>> say to go out of the way to do something else.
>>>
>>
>> Too late, ES5+reality happened. You are now proposing to break the web,
>> at the limit. JS implementors will not go for that, so you are wasting your
>> time.
>>
>>
>> It my strawman spec. it says use [[SetInhertiance]] rather than
>>> [[Put]]. Either is a special case semantics and [[SetInheritance]] is a
>>> much more direct expression of the likely user intent.
>>>
>>
>> Direct, schmirect.
>>
>> This is about compatibility and consistency, not what you can edit into a
>> draft. Please reconsider. Must we put this on the next meeting's agenda?
>>
>> /be
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
