Re: Mutable Proto
Le 22/03/2013 19:33, Mark S. Miller a écrit : On Fri, Mar 22, 2013 at 6:03 PM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). Are you referring to the function atLeastFreeVarNames at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/atLeastFreeVarNames.js? It does scan the source using regular expressions to look for all possible identifiers. But it doesn't do a full parse or even lex. As a result, it picks up identifiers in comments and literal strings as well. Security only requires that the code being scanned cannot contain have a free (and therefore global) variable reference without it being included in atLeastFreeVarNames's result. Yes, exactly, indeed it's not parsing but rexexpeing. But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Nothing official yet. But see https://code.google.com/p/google-caja/wiki/SES http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/37199.pdf Thanks, for [1] there is a script supposed to tame the page, trying to use a kind of home-made Object.observe which just shadows some DOM prototype properties and assign getters/setters, unexpectedly the behavior is different in each browser, and globally this does not work at all as such, maybe the override problem, more probably when I am back to it. [1] http://www.ianonym.com Regards, -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
[+google-caja-discuss] On Sun, Mar 24, 2013 at 10:44 AM, Aymeric Vitte vitteayme...@gmail.com wrote: Le 22/03/2013 19:33, Mark S. Miller a écrit : On Fri, Mar 22, 2013 at 6:03 PM, Aymeric Vitte vitteayme...@gmail.com wrote: As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). Are you referring to the function atLeastFreeVarNames at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/atLeastFreeVarNames.js? It does scan the source using regular expressions to look for all possible identifiers. But it doesn't do a full parse or even lex. As a result, it picks up identifiers in comments and literal strings as well. Security only requires that the code being scanned cannot contain have a free (and therefore global) variable reference without it being included in atLeastFreeVarNames's result. Yes, exactly, indeed it's not parsing but rexexpeing. But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Nothing official yet. But see https://code.google.com/p/google-caja/wiki/SES http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/37199.pdf Thanks, for [1] there is a script supposed to tame the page, trying to use a kind of home-made Object.observe which just shadows some DOM prototype properties and assign getters/setters, You should check out the rest of Caja, which is an integrated solution that uses * SES to secure the JavaScript portion if on an ES5 platform * ES5/3 to emulate ES5 and SES when on a pre-ES5 browser * Domado to tame the DOM and browser API * HTML and CSS rewriters that sanitize by sandboxing the scripts they encounter rather than removing them. unexpectedly the behavior is different in each browser, and globally this does not work at all as such, maybe the override problem, more probably when I am back to it. When used through Caja, the allowed subset of browser behaviors appear much more uniform and reliable. * SES compensates for the override mistake with cajaVM.tamperProof https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#371 and cajaVM.def https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#891 . * ES5/3 purposely does not emulate the ES5 override mistake. This has not broken anything yet, giving us further evidence that this mistake might still be repairable. * Domado presents a more regular browser API, compensating for many differences of the underlying platform. * The HTML and CSS rewriters emit normalized HTML and CSS, so you don't need to worry about differences in how browsers parse the abnormal cases. I hope these are useful for you. Further discussion which is Caja specific and not of general interest should occur on google-caja-disc...@googlegroups.com (cc'ed). [1] http://www.ianonym.com Regards, -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Regards, [1] https://gist.github.com/Ayms/2995641#another-approach-can-be-cajavm- Le 21/03/2013 22:17, Kevin Reid a écrit : Correction: On Thu, Mar 21, 2013 at 2:16 PM, Kevin Reid kpr...@google.com mailto:kpr...@google.com wrote: Yes. SES requires 'with' as a means to hook into 'global' variable reads and writes; without it, it is impossible without performing a parse and scope analysis of the code to be evaluated to emulate the semantics of browser global environments, such as in: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On Fri, Mar 22, 2013 at 6:03 PM, Aymeric Vitte vitteayme...@gmail.comwrote: As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). Are you referring to the function atLeastFreeVarNames at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/atLeastFreeVarNames.js? It does scan the source using regular expressions to look for all possible identifiers. But it doesn't do a full parse or even lex. As a result, it picks up identifiers in comments and literal strings as well. Security only requires that the code being scanned cannot contain have a free (and therefore global) variable reference without it being included in atLeastFreeVarNames's result. But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Nothing official yet. But see https://code.google.com/p/google-caja/wiki/SES http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/37199.pdf Regards, [1] https://gist.github.com/Ayms/2995641#another-approach-can-be-cajavm- Le 21/03/2013 22:17, Kevin Reid a écrit : Correction: On Thu, Mar 21, 2013 at 2:16 PM, Kevin Reid kpr...@google.com wrote: Yes. SES requires 'with' as a means to hook into 'global' variable reads and writes; without it, it is impossible without performing a parse and scope analysis of the code to be evaluated to emulate the semantics of browser global environments, such as in: ___ es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
yes, SES, the non real world out there, needs __proto__ ... shenanigans all over the world because of '__proto__' ain't important. Thanks to be clear on it On Wed, Mar 20, 2013 at 10:18 PM, Brendan Eich bren...@mozilla.com wrote: Your writing is unclear and overlong, and full of unjustified airs of grievance -- please work on it. To recap yet again (last time): __proto__ is a de-facto standard we cannot defeat, whether anyone likes it or not. Adding Object.setPrototypeOf does not help, because code won't migrate to it completely so we'll be stuck with two APIs. If against all odds, all code everywhere *did* magically drop __proto__ in favor of Object.setPrototypeOf, then SES and similar subsets would be unable to protect secure code from ambient Object.setPrototypeOf usage from the insecure side on the secure side's objects, unless Object.setPrototypeOf were removed -- but that would break insecure-side code that reasonably (per your wishes) uses Object.setPrototypeOf in lieu of __proto__. Now do you understand? /be Andrea Giammarchi wrote: never cared about IE much on mobile and I do not care about 100% or __proto__ support ... there is 100% of Object.prototype pollution support since ever and everybody knows that is a bad technique, specially done through direct property rather than through a descriptor. What is the point then ? Should I feel free to shoot in my foot and in all libraries foot because I can change even Object.prototype.__proto__ ? I don't think so and I don't understand what is anyone point here. TC39 decided to do not even talk about __proto__ now is the best thing ever to suggest and use because supported ... is not standard and loads of shenanigans, is an undesired property full of undesired behaviors ... and still you all are protecting it for which reason, exactly? Either you make it standard, or you get rid of it ASAP allowing developers that use it already to migrate, gracefully, through Object.setPrototypeOf ... and considering setPrototypeOf, hidePrototypeOf, and freezePrototypeOf method in ES7 ... how does that sound? 'cause otherwise we can just stop reading specs, if non standard stuff is sacre more than specs and standards or potential, better, solutions. Best Regards On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron waldron.r...@gmail.commailto: waldron.r...@gmail.com** wrote: On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammarchi@**gmail.comandrea.giammar...@gmail.com wrote: I think zepto is using that to modify runtime NodeList results after querySelectorAll but in any case it was not me saying that __proto__ is used already. I use it only to shim getPrototypeOf to be honest and I don't think is a good idea to use it at all. My point is that Object.setPrototypeOf does not need a property loads of shenanigans as __proto__ is so that no Object.prototype.__proto__ would ever exist anywhere. I don't even know why that existed in first place,to be honest ... so do not use it, pass through Object.setPrototypeOf, same as you would suggest pass through Object.defineProperty instead of using Object.prototype.__**defineGetter__ __defineSetters__, both de facto standards some time ago. IE never implemented the __defineGetter__ __defineSetter__ but they did implement the ES5 Object meta APIs and _are_ implementing __proto__ for parity with browsers that currently support it—this is the big difference. This is in addition to the rationale recorded here https://github.com/rwldrn/**tc39-notes/blob/master/es6/** 2013-01/jan-29.md#45-why-**standardizing-on-__proto__-** and-not-__definegsetter__-__**lookupgsetter__https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__ Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Mutable Proto
If against all odds, all code everywhere *did* magically drop __proto__
in favor of Object.setPrototypeOf, then SES and similar subsets would be
unable to protect secure code from ambient Object.setPrototypeOf usage
from the insecure side on the secure side's objects, unless
Object.setPrototypeOf were removed -- but that would break insecure-side
code that reasonably (per your wishes) uses Object.setPrototypeOf in
lieu of __proto__.
Well, I don't completely agree with you on this. It would be easy to protect
objects using
Object.freezePrototype(o)
or
Object.definePrototypeSetter(o, function(o,p) {
if(isValid(p)) return p else throw new Error('...');
}).
I would really like to know how you expect SES to secure a property that lays
in the Object.prototype object and could be overriden by a malicious object to
intercept your __proto__ setter calls.
BTW, you could also *redefine* Object.setPrototypeOf to match your security
requirements without completely removing it.
I know it's not your point of view, but if MSFT never implements __proto__ in
IE (except behind a 'compatibility' mode for sites that rely on it, in the
Opera's browser.js way) and if everbody do implement Object.setPrototypeOf(...)
then the few libraries using __proto__ will end up migrating to
Object.setPrototypeOf(...) or use a polyfill for __proto__ in the case it isn't
supported.
Phasing out failed experiments *is* possible. I don't think a browser that
doesn't support blink or marquee or even document.layers would have a lot
of problems to view the web as it's now, yet I remember a time where
document.layers marquee were used quite a lot. I do think the argument used
to claim __proto__ is unfixable is somewhat wrong.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Andrea Giammarchi wrote: yes, SES, the non real world out there, needs __proto__ ... shenanigans all over the world because of '__proto__' ain't important. SES is deployed on major Google properties. I recall also Yahoo! but not sure if still up. I think again you are out of line. Am I wrong? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On Thu, Mar 21, 2013 at 2:38 AM, François REMY francois.remy@outlook.com wrote: Phasing out failed experiments *is* possible. I don't think a browser that doesn't support blink or marquee or even document.layers would have a lot of problems to view the web as it's now, yet I remember a time where document.layers marquee were used quite a lot. I do think the argument used to claim __proto__ is unfixable is somewhat wrong. Whether or not a failed experiment can be phased out is an empirical question. The answer depends on Web content. marquee is essential in some locales. blink is already a no-op visually. I think JSC and Opera each did without mutable __proto__ for a while and ended up implementing it for Web compatibility. So the experiment has actually been carried out at least twice. Maybe things have changed, but I wouldn't bet on it. New things are added to the Web rapidly. Old things disappear slowly. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
No 'with' required for SES AFAIK. Do you have a code.google.com link? Cc'ing Mark in case he is not reading es-discuss frequently. /be Brandon Benvie wrote: On 3/21/2013 11:39 AM, Brendan Eich wrote: Andrea Giammarchi wrote: yes, SES, the non real world out there, needs __proto__ ... shenanigans all over the world because of '__proto__' ain't important. SES is deployed on major Google properties. I recall also Yahoo! but not sure if still up. I think again you are out of line. Am I wrong? I don't agree with Andrea's sentiment, but this would still be surprising to me. I would have thought that SES's use of `with` to sandbox code (it does this right?) would destroy performance to the point of being unusable in practice. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On 3/21/2013 1:57 PM, Brendan Eich wrote: No 'with' required for SES AFAIK. Do you have a code.google.com link? Cc'ing Mark in case he is not reading es-discuss frequently. /be Brandon Benvie wrote: On 3/21/2013 11:39 AM, Brendan Eich wrote: Andrea Giammarchi wrote: yes, SES, the non real world out there, needs __proto__ ... shenanigans all over the world because of '__proto__' ain't important. SES is deployed on major Google properties. I recall also Yahoo! but not sure if still up. I think again you are out of line. Am I wrong? I don't agree with Andrea's sentiment, but this would still be surprising to me. I would have thought that SES's use of `with` to sandbox code (it does this right?) would destroy performance to the point of being unusable in practice. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss If I understand correctly, this wrapper code is used for all code executed in SES (but I may be wrong): http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#643 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On Thu, Mar 21, 2013 at 10:04 PM, Brandon Benvie bben...@mozilla.comwrote: On 3/21/2013 1:57 PM, Brendan Eich wrote: No 'with' required for SES AFAIK. Do you have a code.google.com link? Cc'ing Mark in case he is not reading es-discuss frequently. Thanks. If I understand correctly, this wrapper code is used for all code executed in SES (but I may be wrong): http://code.google.com/p/** google-caja/source/browse/**trunk/src/com/google/caja/ses/** startSES.js#643http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#643 Yes, to implement SES on ES5, ironically we need to use 'with' and therefore still need to run this bare bit of JS in sloppy mode. In ES6 we should be able to replace all this by using loaders. SES-on-ES6 should no longer need to run any code sloppily. Once someone has an adequate loader implementation, let us know so we can try it. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Brandon Benvie wrote: On 3/21/2013 1:57 PM, Brendan Eich wrote: No 'with' required for SES AFAIK. Do you have a code.google.com link? Cc'ing Mark in case he is not reading es-discuss frequently. First, it doesn't matter: my point about SES being deployed in the real world stands, whether SES uses 'with' or not. Second, a strict mode function scoped by 'with' may not be as deoptimized as you think in all engines. Third, I am surprised but Mark will say more, I'm sure. /be /be Brandon Benvie wrote: On 3/21/2013 11:39 AM, Brendan Eich wrote: Andrea Giammarchi wrote: yes, SES, the non real world out there, needs __proto__ ... shenanigans all over the world because of '__proto__' ain't important. SES is deployed on major Google properties. I recall also Yahoo! but not sure if still up. I think again you are out of line. Am I wrong? I don't agree with Andrea's sentiment, but this would still be surprising to me. I would have thought that SES's use of `with` to sandbox code (it does this right?) would destroy performance to the point of being unusable in practice. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss If I understand correctly, this wrapper code is used for all code executed in SES (but I may be wrong): http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#643 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Correction: On Thu, Mar 21, 2013 at 2:16 PM, Kevin Reid kpr...@google.com wrote: Yes. SES requires 'with' as a means to hook into 'global' variable reads and writes; without it, it is impossible without performing a parse and scope analysis of the code to be evaluated to emulate the semantics of browser global environments, such as in: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On Wed, Mar 20, 2013 at 10:18 PM, Brendan Eich bren...@mozilla.com wrote: Your writing is unclear and overlong, and full of unjustified airs of grievance -- please work on it. I'll do more than that, I publicly and officially apologies for my writing plus I will step back from this ML for an undefined amount of time so you can all keep doing your best to make JavaScript awesome without me bothering at all. Just please, don't forget that not everyone needs to interpretate ES runtime if not online IDEs or some other use case, as SES is ... but those are use cases indeed and those are not the Web and should not affect the future of a programming language that happily runs already on the server too and would like to be **as unsafe as possible when needed** (runtime optimized pre-compiled Function(string) is only a case, fn.caller could be another, etc) but **also a better language when it is possible** (i.e. Object.setPrototypeOf() deprecating the __proto__ magic) Last, but not least, all I've always tried to do in this ML since ever is exactly the same you all do every day: make the Web awesome, caring for all possible real use-cases I've experienced in my 12+ hands on client/server/db web development experience and all of them with JS on the front or the back end. Well, it is quite clear to me that here, in this ML, I've failed. Best Regards ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Mutable Proto
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We definitely need mutable prototype, but having it via __proto__ really
breaks the language.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
That's bad, and it's hard for me to believe we can't do it better.
François REMY-3 wrote:
I certainly agree, but it has been decided otherwhise by the TC39 members
and I doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com wrote:
A previous thread [1] brought to my attention the fact that objects which
don't inherit from Object.prototype won't have mutable __proto__. This
was something I had missed and breaks some scripts I'm currently using
because I have objects which I don't want to inherit from Object.prototype
but for which I do want to have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation? Or
will this be the spec'ed behavior for ES6? Can we use such a method to
mutate prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Mutable-Proto-tp35188550p35196276.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On Wed, Mar 20, 2013 at 5:51 AM, Mariusz Nowak
medikoo+mozilla@medikoo.com wrote:
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
This was recorded as the resolution of record in January 2013
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-proto-and-not-definegsetter-lookupgsetter,
specifically:
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
Rick
We definitely need mutable prototype, but having it via __proto__ really
breaks the language.
Any function that blindly extends object with provided hash is affected
e.g.
extend(obj, { __proto__: Error.prototype }).
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
That's bad, and it's hard for me to believe we can't do it better.
François REMY-3 wrote:
I certainly agree, but it has been decided otherwhise by the TC39 members
and I doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com
wrote:
A previous thread [1] brought to my attention the fact that objects which
don't inherit from Object.prototype won't have mutable __proto__. This
was something I had missed and breaks some scripts I'm currently using
because I have objects which I don't want to inherit from
Object.prototype
but for which I do want to have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation?
Or
will this be the spec'ed behavior for ES6? Can we use such a method to
mutate prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Mutable-Proto-tp35188550p35196276.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Mariusz Nowak wrote:
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We've been over this many times, e.g. at
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
To recap,
1. __proto__ is out in the field, a de-facto standard on mobile, and
not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object, realm)
mashups of code that may use __proto__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Mutable Proto
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of discussion in the past and there are reasons for the current decision.
I will see how I can make my code cope with reality.
Nathan
Brendan Eich wrote:
Mariusz Nowak wrote:
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We've been over this many times, e.g. at
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
To recap,
1. __proto__ is out in the field, a de-facto standard on mobile, and
not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object, realm)
mashups of code that may use __proto__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Le 20/03/2013 16:36, Nathan Wall a écrit :
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of discussion in the past and there are reasons for the current decision.
I will see how I can make my code cope with reality.
Could you describe how you use __proto__ on objects not inheriting from
Object.prototype?
From what I know there are 2 main use cases:
1) object as map
changing the prototype enable changing different default values. I
guess any solution to that problem either looses the object syntax
(maybe unless using proxies) like using an ES6 Map or has non-trivial
runtime cost.
Or the code needs to be reorganized so that the object is always created
after the prototype (using Object.create for instance)
2) Subclassing
ES6 will have classes with inheritance. That's mostly syntax sugar on
top of what's already possible, but that works.
Do you have a use case that belongs in neither of these categories?
David
Nathan
Brendan Eich wrote:
Mariusz Nowak wrote:
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We've been over this many times, e.g. at
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html
To recap,
1. __proto__ is out in the field, a de-facto standard on mobile, and
not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object, realm)
mashups of code that may use __proto__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty
or equivalent, then nothing is broken and the setter on Object.prototype
for __proto__ is not run.
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to
Object.prototype, but see (1) above: this hazard already exists. Don't
do that; JSON doesn't, and Object.create(null) gives a way to create
dictionaries.
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a
mistake due to (2).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
Le 20/03/2013 16:15, Brendan Eich a écrit : To recap, 1. __proto__ is out in the field, a de-facto standard on mobile, and not going away. Adding another API doesn't help, it hurts. 2. SES and other secure subsets want same-frame (global object, realm) mashups of code that may use __proto__ and code that must not, but Object.setPrototypeOf is a per-frame capability that would have to be removed, breaking the former class of code. (...) Yes, the problems you cite are real, but they are already part of the de-facto __proto__ standard (1). Agreed. From the spec/implementor point of view, __proto__ has to be added as de-facto standard because it is used. From the developer point of view, it is not because it's in the language that it's a good idea to use it. Quite the opposite, I'd like to reiterate that devs should make delete Object.prototype.__proto__ the second line of their code (first line is use strict;). Devs shouldn't make the mistake to think that __proto__ in the standard makes it a good or legitimate feature. __proto__ in ES6 is yet another ECMAScript Regret [1] David [1] https://github.com/DavidBruant/ECMAScript-regrets (I haven't found much time to write more, but issues are more interesting to read than just the part that's been written down) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
I don't understand where is the problem ... any library that uses __proto__
can and should be updated with a shim waiting for next version of JS to
support it.
Object.setPrototypeOf = function (object, proto) {
object.__proto__ = proto;
return object;
};
That does not look bad at all to me, educate developers out there that
__proto__ is harmful and forbidden 'cause saying we can't do much is
already used doesn't mean is OK to use it, same as polluting
Object.prototype, still possible, nobody does it (not in an old fashioned
way at least)
Best Regards
On Wed, Mar 20, 2013 at 9:27 AM, David Bruant bruan...@gmail.com wrote:
Le 20/03/2013 16:15, Brendan Eich a écrit :
To recap,
1. __proto__ is out in the field, a de-facto standard on mobile, and
not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object, realm)
mashups of code that may use __proto__ and code that must not, but
Object.setPrototypeOf is a per-frame capability that would have to be
removed, breaking the former class of code.
(...)
Yes, the problems you cite are real, but they are already part of the
de-facto __proto__ standard (1).
Agreed.
From the spec/implementor point of view, __proto__ has to be added as
de-facto standard because it is used.
From the developer point of view, it is not because it's in the language
that it's a good idea to use it. Quite the opposite, I'd like to reiterate
that devs should make delete Object.prototype.__proto__ the second line
of their code (first line is use strict;).
Devs shouldn't make the mistake to think that __proto__ in the standard
makes it a good or legitimate feature.
__proto__ in ES6 is yet another ECMAScript Regret [1]
David
[1]
https://github.com/**DavidBruant/ECMAScript-regretshttps://github.com/DavidBruant/ECMAScript-regrets(I
haven't found much time to write more, but issues are more interesting
to read than just the part that's been written down)
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
never cared about IE much on mobile and I do not care about 100% or __proto__ support ... there is 100% of Object.prototype pollution support since ever and everybody knows that is a bad technique, specially done through direct property rather than through a descriptor. What is the point then ? Should I feel free to shoot in my foot and in all libraries foot because I can change even Object.prototype.__proto__ ? I don't think so and I don't understand what is anyone point here. TC39 decided to do not even talk about __proto__ now is the best thing ever to suggest and use because supported ... is not standard and loads of shenanigans, is an undesired property full of undesired behaviors ... and still you all are protecting it for which reason, exactly? Either you make it standard, or you get rid of it ASAP allowing developers that use it already to migrate, gracefully, through Object.setPrototypeOf ... and considering setPrototypeOf, hidePrototypeOf, and freezePrototypeOf method in ES7 ... how does that sound? 'cause otherwise we can just stop reading specs, if non standard stuff is sacre more than specs and standards or potential, better, solutions. Best Regards On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I think zepto is using that to modify runtime NodeList results after querySelectorAll but in any case it was not me saying that __proto__ is used already. I use it only to shim getPrototypeOf to be honest and I don't think is a good idea to use it at all. My point is that Object.setPrototypeOf does not need a property loads of shenanigans as __proto__ is so that no Object.prototype.__proto__ would ever exist anywhere. I don't even know why that existed in first place,to be honest ... so do not use it, pass through Object.setPrototypeOf, same as you would suggest pass through Object.defineProperty instead of using Object.prototype.__defineGetter__ __defineSetters__, both de facto standards some time ago. IE never implemented the __defineGetter__ __defineSetter__ but they did implement the ES5 Object meta APIs and _are_ implementing __proto__ for parity with browsers that currently support it—this is the big difference. This is in addition to the rationale recorded here https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__ Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Mutable Proto
A previous thread [1] brought to my attention the fact that objects which don't
inherit from Object.prototype won't have mutable __proto__. This was something
I had missed and breaks some scripts I'm currently using because I have objects
which I don't want to inherit from Object.prototype but for which I do want to
have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation? Or will
this be the spec'ed behavior for ES6? Can we use such a method to mutate
prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com wrote:
A previous thread [1] brought to my attention the fact that objects which
don't inherit from Object.prototype won't have mutable __proto__. This was
something I had missed and breaks some scripts I'm currently using because
I have objects which I don't want to inherit from Object.prototype but for
which I do want to have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation? Or
will this be the spec'ed behavior for ES6? Can we use such a method to
mutate prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Mutable Proto
I certainly agree, but it has been decided otherwhise by the TC39 members and I
doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a disappeared
__proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather than
fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com wrote:
A previous thread [1] brought to my attention the fact that objects which don't
inherit from Object.prototype won't have mutable __proto__. This was something
I had missed and breaks some scripts I'm currently using because I have objects
which I don't want to inherit from Object.prototype but for which I do want to
have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation? Or will
this be the spec'ed behavior for ES6? Can we use such a method to mutate
prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
