RE: A Precedent

2013-04-14 Thread Nathan Wall
Brendan Eich wrote: ... https://mail.mozilla.org/pipermail/es-discuss/2013-February/028631.html It looks like the setter throws only if called on an object from a different realm, so maybe it will work for your intended uses. It won't work cross-frame, in other words. /be Great!  Will the

Re: A Precedent

2013-04-14 Thread Andrea Giammarchi
at least in Firefox is working like that: var blackMagic = Object.getOwnPropertyDescriptor( Object.prototype, '__proto__' ).set; var NaO = Object.create(null); var o = {}; blackMagic.call(NaO, o); o.isPrototypeOf(NaO); // true if this will work cross browser like this adopting a method

Re: A Precedent

2013-04-13 Thread David Bruant
Le 13/04/2013 03:31, Andrea Giammarchi a écrit : Do you read internet where every developer calls __proto__ ugly ? I do read the Internet [1]. I believe Brendan and all TC39 do too. Let's be super careful when using every/all/no/none/always/never and other superlatives. History happened in

Re: A Precedent

2013-04-12 Thread gaz Heyes
On 12 April 2013 09:01, Andrea Giammarchi andrea.giammar...@gmail.comwrote: // all Mobile WebKit browsers *if* ('__proto__' *in* Object.create(*null*)) { console.log('you gonna have hard time'); } If this is true that means it breaks the *only *way of creating a secure lookup table.

Re: A Precedent

2013-04-12 Thread Alex Russell
Hey Andrea, Response inline. On Fri, Apr 12, 2013 at 9:01 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: a principle or rule established in a previous case: http://en.wikipedia.org/wiki/Precedent I should not be here and I will not answer, just my last attempt trying to make a

Re: A Precedent

2013-04-12 Thread Andrea Giammarchi
Alex, I wrote that with best intents. I have the incredible ability to transform any thread in a flame so for this mailing list sake is better, as I've written already, to be as far away as possible (I keep watching threads though). I'll try to quickly answer: @gaz, yes, dictionaries and lookup

Re: A Precedent

2013-04-12 Thread Brendan Eich
Andrea Giammarchi wrote: Alex, I wrote that with best intents. I have the incredible ability to transform any thread in a flame so for this mailing list sake is better, as I've written already, to be as far away as possible (I keep watching threads though). At least read up on the topic. A

Re: A Precedent

2013-04-12 Thread Brendan Eich
Brendan Eich wrote: AFAIK, Chromium might solve this soon so no need to fork it? http://code.google.com/p/v8/source/detail?r=14139 No, because the setter will be poisoned, per ... https://mail.mozilla.org/pipermail/es-discuss/2013-February/028631.html It looks like the setter throws only

Re: A Precedent

2013-04-12 Thread Andrea Giammarchi
Adding Object.setPrototypeOf does not help, because code won't migrate to it completely so we'll be stuck with two APIs. As shown in the first post we'll be stuck with 4 APIs plus the 5th one standardized. The __proto__ that is not supported, the one that is wrongly inherited in

Re: A Precedent

2013-04-12 Thread Brendan Eich
Andrea Giammarchi wrote: Adding Object.setPrototypeOf does not help, because code won't migrate to it completely so we'll be stuck with two APIs. As shown in the first post we'll be stuck with 4 APIs plus the 5th one standardized. What 4 APIs are you talking about? The __proto__ that is

Re: A Precedent

2013-04-12 Thread Andrea Giammarchi
if you consider Object.setPrototypeOf an API and __proto__ another one then I consider all variants of __proto__ other APIs As you said we cannot get rid of so standardizing an extra one on top will create 5 different scenarios. Old __proto__ will go away, same could be for __proto__ if ES6 will

Re: A Precedent

2013-04-12 Thread Brendan Eich
Andrea Giammarchi wrote: if you consider Object.setPrototypeOf an API and __proto__ another one then I consider all variants of __proto__ other APIs As *I* just wrote, this counting old pre-ES6 __proto__ variations is unfair because ES6 can't affect browsers in the field. Knock it off. As

Re: A Precedent

2013-04-12 Thread Andrea Giammarchi
he doesn't need to fork V8, he simply needs to delete Object.prototype.__proto__; at startup time so I am getting real On Fri, Apr 12, 2013 at 6:21 PM, Brendan Eich bren...@mozilla.com wrote: Andrea Giammarchi wrote: if you consider Object.setPrototypeOf an API and __proto__ another one

Re: A Precedent

2013-04-12 Thread Brendan Eich
Andrea Giammarchi wrote: he doesn't need to fork V8, he simply needs to delete Object.prototype.__proto__; I double-dog dare anyone to do this and keep all the NPM modules working. There won't be a standard Object.setPrototypeOf. Maybe it's time to stop the same runaround as last month, at

Re: A Precedent

2013-04-12 Thread Andrea Giammarchi
also, too much power because of a function instead of a hot/swap through a property ? who told you nobody wants that function because prefer __proto__ instead ? Do you read internet where every developer calls __proto__ ugly ? And btw, which part I did not reply ... I have no idea, honestly!