Re: B.3.1 The __proto__ pseudo property

consider this then, same thing JSON is doing now in FF and Safari ``` var obj = Object.defineProperty({}, '__proto__', { enumerable: true, writable: true, configurable: true, value: [] }); console.log(obj instanceof Array); // false obj.__proto__ = Array.prototype; console.log(obj instanc

Re: B.3.1 The __proto__ pseudo property

On 5/21/2013 9:43 AM, Andrea Giammarchi wrote: On Tue, May 21, 2013 at 12:56 AM, Brendan Eich > wrote: Andrea Giammarchi wrote: can I also suggest to analyze, if there's still any doubt left on a method VS a property yet, this piece of code if not

Re: B.3.1 The __proto__ pseudo property

for always work I meant as long as the object is not sealed/frozen as discussed a while ago On Tue, May 21, 2013 at 9:43 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > On Tue, May 21, 2013 at 12:56 AM, Brendan Eich wrote: > >> Andrea Giammarchi wrote: >> >>> can I also suggest to

Re: B.3.1 The __proto__ pseudo property

On Tue, May 21, 2013 at 12:56 AM, Brendan Eich wrote: > Andrea Giammarchi wrote: > >> can I also suggest to analyze, if there's still any doubt left on a >> method VS a property yet, this piece of code if not highlighted before? >> > > I do not understand what you mean here. > > I mean that JSON,

Re: B.3.1 The __proto__ pseudo property

2013/5/20 Andrea Giammarchi > I believe having a counterpart in the Object, following a natural > expectation where for a get you've got a set, is just fine but surely > Reflect should have its own "reflection power" a part. > Yeah, given the existence of Object.getPrototypeOf, I agree it would

Re: B.3.1 The __proto__ pseudo property

Andrea Giammarchi wrote: can I also suggest to analyze, if there's still any doubt left on a method VS a property yet, this piece of code if not highlighted before? I do not understand what you mean here. Behavior in Safari and FirefoxNightly (V8 still by its own here) ``` var obj = JSON.pa

Re: B.3.1 The __proto__ pseudo property

On 5/20/2013 5:58 PM, Andrea Giammarchi wrote: can I ask when is next TC39 meeting? Starts tomorrow. http://wiki.ecmascript.org/doku.php?id=meetings:meetings ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discu

Re: B.3.1 The __proto__ pseudo property

can I ask when is next TC39 meeting? can I also suggest to analyze, if there's still any doubt left on a method VS a property yet, this piece of code if not highlighted before? Behavior in Safari and FirefoxNightly (V8 still by its own here) ``` var obj = JSON.parse('{"__proto__":[]}'); console.

Re: B.3.1 The __proto__ pseudo property

Andrea Giammarchi wrote: that's fine with what I am thinking/saying ... it's used as reflection, to intercept, or to trap, and not used to "do the action" of setting the prototype so `Object` is, and you confirmed this, a better place for `setPrototypeOf` No, Brandon wrote: "[for every meta

Re: B.3.1 The __proto__ pseudo property

that's fine with what I am thinking/saying ... it's used as reflection, to intercept, or to trap, and not used to "do the action" of setting the prototype so `Object` is, and you confirmed this, a better place for `setPrototypeOf` On Mon, May 20, 2013 at 11:29 AM, Brandon Benvie wrote: > On 5/20

Re: B.3.1 The __proto__ pseudo property

On 5/20/2013 10:55 AM, Andrea Giammarchi wrote: I believe having a counterpart in the Object, following a natural expectation where for a get you've got a set, is just fine but surely Reflect should have its own "reflection power" a part. I see Reflect more like an introspection tool able to u

Re: B.3.1 The __proto__ pseudo property

I believe having a counterpart in the Object, following a natural expectation where for a get you've got a set, is just fine but surely Reflect should have its own "reflection power" a part. I see Reflect more like an introspection tool able to understand things and not necessarily mutate them ( y

Re: B.3.1 The __proto__ pseudo property

2013/5/20 Andrea Giammarchi > does `Proxy` trap `Object.getPrototypeOf` somehow ? > If yes, why do you think having two namespaces for the prototype operation > is better? > If not, why do you think that is not needed in case of getting the > prototype? > Yes, there's a `getPrototypeOf` trap. I

Re: B.3.1 The __proto__ pseudo property

does `Proxy` trap `Object.getPrototypeOf` somehow ? If yes, why do you think having two namespaces for the prototype operation is better? If not, why do you think that is not needed in case of getting the prototype? In any case, how `Object.setPrototypeOf` differs anyhow compared to how the `__pro

Re: B.3.1 The __proto__ pseudo property

2013/5/9 Brendan Eich > Andreas Rossberg wrote: > >(And let's bury setPrototypeOf quickly.) >> > > Bury how? IIUC this goes in main spec alongside ES5's > Object.getPrototypeOf, requires a proxy trap, etc. Here's one potential alternative: add Reflect.setPrototypeOf but not Object.setProtot

Re: B.3.1 The __proto__ pseudo property

Le 09/05/2013 18:14, Brendan Eich a écrit : Andreas Rossberg wrote: > But not __proto__ -- dream on if you think that is going away any time soon! I was thinking about V8 embedders other than browsers who could toggle that flag. Node won't, if I recall correctly. Any other embeddings of not

Re: B.3.1 The __proto__ pseudo property

Jeff Walden wrote: On 05/09/2013 10:12 AM, Brendan Eich wrote: Adding an equivalent to the main spec does not cordon off the mis-performing (non-performant?) functionality. I may have misread, but I had thought there was argument to put Object.setPrototypeOf in Annex B as well. No, main sp

Re: B.3.1 The __proto__ pseudo property

On 05/09/2013 10:12 AM, Brendan Eich wrote: > Adding an equivalent to the main spec does not cordon off the mis-performing > (non-performant?) functionality. I may have misread, but I had thought there was argument to put Object.setPrototypeOf in Annex B as well. If it's added, that seems like

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg wrote: > But not __proto__ -- dream on if you think that is going away any time soon! I was thinking about V8 embedders other than browsers who could toggle that flag. Node won't, if I recall correctly. Any other embeddings of note? And I absolutely do think that should

Re: B.3.1 The __proto__ pseudo property

Jeff Walden wrote: On 05/08/2013 04:10 PM, Brendan Eich wrote: Why would Object.setPrototypeOf have any better perf? It wouldn't. Then I don't know why you wrote "The reason would be to cordon off functionality whose mis-performance developers will not intuitively understand, so that they'

Re: B.3.1 The __proto__ pseudo property

I would rather bury __proto__ sooner through a --no-black-magic-in-object-prototype V8 flag but again, I proposed a flag and V8 said they don't want to go for this direction ... **actually it was you saying that** https://code.google.com/p/v8/issues/detail?id=2645#c3 "We have no interest in fragm

Re: B.3.1 The __proto__ pseudo property

On 8 May 2013 22:58, Brendan Eich wrote: > Andreas Rossberg wrote: >> >> On 8 May 2013 18:06, David Bruant wrote: >>> >>> Le 08/05/2013 08:01, Andreas Rossberg a écrit : >>> On 8 May 2013 07:10, Mark Miller wrote: > > What would be gained by > moving the property alone to Annex

Re: B.3.1 The __proto__ pseudo property

it took 8 years to teach JS developers **not** to pollute Object.prototype, I understand your concern and I understand with the possibility to drop enumerability that could (and will) be proposed by someone. At the same time it will be a stubborn move aim to fix some deprecated, old, not maintaine

Re: B.3.1 The __proto__ pseudo property

On 05/08/2013 04:10 PM, Brendan Eich wrote: > Why would Object.setPrototypeOf have any better perf? It wouldn't. >> developers will not intuitively understand, so that they're less likely to >> use it. Some will, even still, perhaps just out of obstinacy ("pride", > > I think you missed that

Re: B.3.1 The __proto__ pseudo property

meanwhile, if V8 devs would like to play with the "how knows if/where to put it" proposal, I've landed a patch that polish __proto__ poison from V8 and add, with tests I could think of, Object.setPrototypeOf native: https://code.google.com/p/v8/issues/attachmentText?id=2675&aid=2675000&name=set

Re: B.3.1 The __proto__ pseudo property

Jeff Walden wrote: On 05/08/2013 01:58 PM, Brendan Eich wrote: 1. Dumping stuff into Annex B to show disdain. This is pride, bad for the soul. "Pride" doesn't seem like a reason one way or the other, to me. Good. The reason would be to cordon off functionality whose mis-performance Wh

Re: B.3.1 The __proto__ pseudo property

On May 8, 2013, at 2:05 PM, Brendan Eich wrote: > Having Object.setPrototypeOf to match Object.getPrototypeOf is nice, better > for proxies (with necessary changes to them), and polyfillable. > > Take my last note as an attitude adjustment, though. So long as __proto__ > endures, its brevity a

Re: B.3.1 The __proto__ pseudo property

Dean Landolt wrote: Call me crazy but I can picture a world where you have to explicitly shim in __proto__ (using Object.setPrototypeOf) if you really need it. Not anytime soon, sure, but maybe one day. Maybe... Who can say? It's fruitless to speculate idly. Want to bet? But aside from wagers

Re: B.3.1 The __proto__ pseudo property

On 05/08/2013 01:58 PM, Brendan Eich wrote: > 1. Dumping stuff into Annex B to show disdain. This is pride, bad for the > soul. "Pride" doesn't seem like a reason one way or the other, to me. The reason would be to cordon off functionality whose mis-performance developers will not intuitively

Re: B.3.1 The __proto__ pseudo property

Call me crazy but I can picture a world where you have to explicitly shim in __proto__ (using Object.setPrototypeOf) if you really need it. Not anytime soon, sure, but maybe one day. Maybe... On Wed, May 8, 2013 at 5:05 PM, Brendan Eich wrote: > Having Object.setPrototypeOf to match Object.getP

Re: B.3.1 The __proto__ pseudo property

Having Object.setPrototypeOf to match Object.getPrototypeOf is nice, better for proxies (with necessary changes to them), and polyfillable. Take my last note as an attitude adjustment, though. So long as __proto__ endures, its brevity and legacy uses will tend to propagate its use into the fut

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg wrote: On 8 May 2013 18:06, David Bruant wrote: Le 08/05/2013 08:01, Andreas Rossberg a écrit : On 8 May 2013 07:10, Mark Miller wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win. JavaScript implementa

Re: B.3.1 The __proto__ pseudo property

On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote: > On 8 May 2013 17:41, Allen Wirfs-Brock wrote: >> >> On May 8, 2013, at 8:31 AM, Mark Miller wrote: >> >>> What about your triangle argument? >> >> There is another way: >> >> let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; >> >>

Re: B.3.1 The __proto__ pseudo property

I proposed a flag for a reusable setter they told me they have no interest to fragment the language behind these kind of flags ... To all: a new syntax is also more suitable for shims/polyfills, something broken/partial implementation of __proto__.set descriptor cannot replace so, as direction, **

Re: B.3.1 The __proto__ pseudo property

On 8 May 2013 18:06, David Bruant wrote: > Le 08/05/2013 08:01, Andreas Rossberg a écrit : > >> On 8 May 2013 07:10, Mark Miller wrote: >>> >>> What would be gained by >>> moving the property alone to Annex B? If nothing, then I think this >>> consistency should win. >> >> JavaScript implementati

Re: B.3.1 The __proto__ pseudo property

On 5/8/2013 9:00 AM, David Bruant wrote: Le 08/05/2013 16:46, Andreas Rossberg a écrit : Isn't Object.create the proper alternative to both {__proto__: } and triangle for objects? What has setPrototypeOf got to do with it? (And why is that on the table all of a sudden?) Object.create only create

Re: B.3.1 The __proto__ pseudo property

Le 08/05/2013 08:01, Andreas Rossberg a écrit : On 8 May 2013 07:10, Mark Miller wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win. JavaScript implementations in new or existing eco systems that are not poisoned by web leg

Re: B.3.1 The __proto__ pseudo property

Le 08/05/2013 16:46, Andreas Rossberg a écrit : On 8 May 2013 17:41, Allen Wirfs-Brock wrote: On May 8, 2013, at 8:31 AM, Mark Miller wrote: What about your triangle argument? There is another way: let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; Let's keep {__proto__: foo} in the

Re: B.3.1 The __proto__ pseudo property

On 8 May 2013 17:41, Allen Wirfs-Brock wrote: > > On May 8, 2013, at 8:31 AM, Mark Miller wrote: > >> What about your triangle argument? > > There is another way: > > let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; > > Let's keep {__proto__: foo} in the slightly disrespectable Annex B b

Re: B.3.1 The __proto__ pseudo property

On May 8, 2013, at 8:31 AM, Mark Miller wrote: > What about your triangle argument? There is another way: let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; Let's keep {__proto__: foo} in the slightly disrespectable Annex B box. That keeps it together with O.p.__proto and leaves room

Re: B.3.1 The __proto__ pseudo property

What about your triangle argument? Cheers --MarkM On May 8, 2013, at 7:53 AM, Allen Wirfs-Brock wrote: > > On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote: > >> On 8 May 2013 07:10, Mark Miller wrote: >>> What would be gained by >>> moving the property alone to Annex B? If nothing, t

Re: B.3.1 The __proto__ pseudo property

On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote: > On 8 May 2013 07:10, Mark Miller wrote: >> What would be gained by >> moving the property alone to Annex B? If nothing, then I think this >> consistency should win. > > JavaScript implementations in new or existing eco systems that are not

Re: B.3.1 The __proto__ pseudo property

On 8 May 2013 07:10, Mark Miller wrote: > What would be gained by > moving the property alone to Annex B? If nothing, then I think this > consistency should win. JavaScript implementations in new or existing eco systems that are not poisoned by web legacy wouldn't be obliged to support it. It's t

Re: B.3.1 The __proto__ pseudo property

The special syntax can't go into Annex B; it must remain in the main text. Allen's message agrees with this. I agree that consistency suggests that the property go in the main text, but doesn't demand it. What would be gained by moving the property alone to Annex B? If nothing, then I think this co

Re: B.3.1 The __proto__ pseudo property

Mark S. Miller wrote: 2) Object.prototype.__proto__ is moved back to Annex B. Since __proto__, unlike __defineGetter__, provides functionality that is otherwise unavailable, all JS platforms will treat it as mandatory whether we put it into Appendix B or the main text. At

Re: B.3.1 The __proto__ pseudo property

Looks like a very clean solution. The only thing I’m not entirely convinced about is Object.setPrototypeOf()... ... given how one is normally discouraged from using such functionality (=__proto__ as a setter) and ... given that the most frequent use case goes away in ES6 (thanks to it allowing

Re: B.3.1 The __proto__ pseudo property

On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller wrote: > On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock < > allen.wirfsbr...@gmail.com> wrote: > >> So here is the plan that I'll review at the next TC39 meeting: >> >> 1) Add Object.setPrototypeOf(obj, proto) >> A obj must be extensible in order

Re: B.3.1 The __proto__ pseudo property

On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock < allen.wirfsbr...@gmail.com> wrote: > So here is the plan that I'll review at the next TC39 meeting: > > 1) Add Object.setPrototypeOf(obj, proto) > A obj must be extensible in order to change its [[Prototype]]. There are > no realm restrictions.

Re: B.3.1 The __proto__ pseudo property

So here is the plan that I'll review at the next TC39 meeting: 1) Add Object.setPrototypeOf(obj, proto) A obj must be extensible in order to change its [[Prototype]]. There are no realm restrictions. It's just like all the other Object.* methods in operating on any object, independent of realm

Re: B.3.1 The __proto__ pseudo property

fine for non-extensible objects, you might desire to keep a dictionary a dictionary though, allowing properties extensions avoiding hot-swap inheritance 2 options in my mind: 1. Object.freezeInheritance(generic), setting a [[MutablePrototype]] internal property to false (true by default) 2. a

Re: B.3.1 The __proto__ pseudo property

On Tue, May 7, 2013 at 11:09 AM, Nathan Wall wrote: > >> Do you think we can come to some sort of agreement, as discussed below, > >> that [[ProtoSetter]] doesn't need to be realm restricted. Such an > >> agreement would let us write the simplest possible specification of > >> __proto__. > > > >

RE: B.3.1 The __proto__ pseudo property

>> Do you think we can come to some sort of agreement, as discussed below,  >> that [[ProtoSetter]] doesn't need to be realm restricted. Such an  >> agreement would let us write the simplest possible specification of  >> __proto__.  >  > Very timely question. I've discussed this within the other Ca

Fwd: B.3.1 The __proto__ pseudo property

From: Mark S. Miller Date: Sun, Apr 28, 2013 at 10:52 AM Subject: Re: B.3.1 The __proto__ pseudo property To: Allen Wirfs-Brock On Sun, Apr 28, 2013 at 10:41 AM, Allen Wirfs-Brock wrote: > (private) > > Do you think we can come to some sort of agreement, as discussed below, > t

Re: B.3.1 The __proto__ pseudo property

Le 23/04/2013 17:52, Allen Wirfs-Brock a écrit : On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote: [*] I say "probably" to hedge my bets. The hard constraint we absolutely require is already guaranteed by ES5: That the [[Prototype]] of a non-extensible object cannot be mutated. Given that, it

Re: B.3.1 The __proto__ pseudo property

To clarify, since I was perhaps "somewhat" terse here. :-) print(eval('[{"__proto__": 17}]')[0].hasOwnProperty("__proto__")); print(eval('[{"__proto__":0x17}]')[0].hasOwnProperty("__proto__")); SunSpider uses eval() on JSONish input, so engines have to make that fast. Most/all engines for

Re: B.3.1 The __proto__ pseudo property

then is more Ha, ha, ha. Lulz, I told you, lulz! this one? '__proto__' in {__proto__:null,"__proto__":null} On Tue, Apr 23, 2013 at 5:34 PM, Jeff Walden wrote: > On 04/21/2013 03:27 PM, Mark S. Miller wrote: > > Warning: The following is a sickening idea. I would really hate to see > us do it

Re: B.3.1 The __proto__ pseudo property

On 04/21/2013 03:27 PM, Mark S. Miller wrote: > Warning: The following is a sickening idea. I would really hate to see us do > it. But I feel obliged to post it as it may in fact be the right thing to do. > > This suggests that, in JS as well, the "__proto__" in {, "__proto__": > , }

Re: B.3.1 The __proto__ pseudo property

You are filing the wrong bug, asking for the wrong thing. What V8 implemented was based on a misunderstanding of the January tentative consensus. The setter should not always throw. We're working through the details to re-establish consensus here, in advance of the mid-May meeting. In the mea

Re: B.3.1 The __proto__ pseudo property

"be careful what you wish" ... if it's about making things that hard on server side JS too. V8 apparently won't accept even a flag for this, regardless zero side effects on web whatever decision is made. https://code.google.com/p/v8/issues/detail?id=2645 This is bad, IMHO! On Tue, Apr 23, 2013

Re: B.3.1 The __proto__ pseudo property

discussion oriented to SES again, I hope this won't be spec'd blindly after some SES requirement that might be very different from, let's say, node.js requirements, where the concept of security is not about evaluating runtime unknonw code ... right? :-) I keep being amazed by how many problems is

Re: B.3.1 The __proto__ pseudo property

On Apr 23, 2013, at 5:18 PM, Andreas Rossberg wrote: > On 23 April 2013 17:10, Mark S. Miller wrote: >> [*] I say "probably" to hedge my bets. The hard constraint we absolutely >> require is already guaranteed by ES5: That the [[Prototype]] of a >> non-extensible object cannot be mutated. > > I

Re: B.3.1 The __proto__ pseudo property

On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote: > On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock > wrote: > Mark, below what you refer to as [[SetProtoype]] is essentially the > [[SetInhertiance]] MOP operations in the current spec. draft there is also a > [[GetInheritance]]. It is ca

Re: B.3.1 The __proto__ pseudo property

On 23 April 2013 17:10, Mark S. Miller wrote: > [*] I say "probably" to hedge my bets. The hard constraint we absolutely > require is already guaranteed by ES5: That the [[Prototype]] of a > non-extensible object cannot be mutated. I'm confused now. How does ES5 guarantee that? /Andreas

Re: B.3.1 The __proto__ pseudo property

On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock wrote: > Mark, below what you refer to as [[SetProtoype]] is essentially the > [[SetInhertiance]] MOP operations in the current spec. draft there is also > a [[GetInheritance]]. It is called Get/SetInheritance because it doesn't > necessarily man

Re: B.3.1 The __proto__ pseudo property

Le 23/04/2013 15:53, Brendan Eich a écrit : David Bruant wrote: Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit : * { [ "__proto__" ]: } is not special in any way, and creates a normal property named "__proto__". I don't believe this is legal. Didn't we agree w to support [ ] property keys

Re: B.3.1 The __proto__ pseudo property

On Apr 23, 2013, at 3:50 PM, Brendan Eich wrote: > Taking bite-sized pieces: > > Allen Wirfs-Brock wrote: >>> > > * { [ "__proto__" ]: } is not special in any way, and creates a >>> > normal property named "__proto__". >> >> I don't believe this is legal. Didn't we agree w to support [

Re: B.3.1 The __proto__ pseudo property

On Apr 23, 2013, at 3:35 PM, Mark Miller wrote: > What is Object.free? ugh, jet lag... Object.freeze > > > On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock > wrote: > Mark, below what you refer to as [[SetProtoype]] is essentially the > [[SetInhertiance]] MOP operations in the current

Re: B.3.1 The __proto__ pseudo property

David Bruant wrote: Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit : * { [ "__proto__" ]: } is not special in any way, and creates a normal property named "__proto__". I don't believe this is legal. Didn't we agree w to support [ ] property keys that evaluate to symbols. I don't know what

Re: B.3.1 The __proto__ pseudo property

Taking bite-sized pieces: Allen Wirfs-Brock wrote: > > * { [ "__proto__" ]: } is not special in any way, and creates a normal property named "__proto__". I don't believe this is legal. Didn't we agree w to support [ ] property keys that evaluate to symbols. No, [n] is good for any co

Re: B.3.1 The __proto__ pseudo property

Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit : * { [ "__proto__" ]: } is not special in any way, and creates a normal property named "__proto__". I don't believe this is legal. Didn't we agree w to support [ ] property keys that evaluate to symbols. I don't know what the agreement is, b

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg wrote: On 22 April 2013 22:15, Allen Wirfs-Brock wrote: We don't currently have the concept of an object "belonging" to a realm. Functions have a realm association, but not non-function object. I thought the current plan of record is to require this check for reflected uses

Re: B.3.1 The __proto__ pseudo property

What is Object.free? On Tue, Apr 23, 2013 at 6:30 AM, Allen Wirfs-Brock wrote: > Mark, below what you refer to as [[SetProtoype]] is essentially the > [[SetInhertiance]] MOP operations in the current spec. draft there is also > a [[GetInheritance]]. It is called Get/SetInheritance because it do

Re: B.3.1 The __proto__ pseudo property

Mark, below what you refer to as [[SetProtoype]] is essentially the [[SetInhertiance]] MOP operations in the current spec. draft there is also a [[GetInheritance]]. It is called Get/SetInheritance because it doesn't necessarily manipulate the [[Prototype]] of the object it is invoked upon (eg,

Re: B.3.1 The __proto__ pseudo property

Agreed. Just to clarify though, I'm going to make a pedantic change to your wording ;). On Tue, Apr 23, 2013 at 6:00 AM, Andreas Rossberg wrote: [...] > Preventing cross-realm prototype chains was not the intention. The > intention was to prevent using a protosetter from another realm to > muta

Re: B.3.1 The __proto__ pseudo property

On 23 April 2013 14:54, Allen Wirfs-Brock wrote: > Even if we had per object realm associations, it isn't clear to me what > exactly we are trying to block WRT cross-realm [[Prototype]] chains. Is the > assertion that all objects in a [[Prototype]] chain must come from the same > realm. Does tha

Re: B.3.1 The __proto__ pseudo property

Aren't sandboxed natives a JS technique that actually relies on cross-realm prototype chains? http://msdn.microsoft.com/en-us/magazine/gg278167.aspx My understanding is that they create a separate origin in order to get their own copies of the natives so that they can fiddle with those natives' p

Re: B.3.1 The __proto__ pseudo property

On Apr 23, 2013, at 3:31 AM, Mark S. Miller wrote: > On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock > wrote: > We don't currently have the concept of an object "belonging" to a realm. > Functions have a realm association, but not non-function object. > > The current idea on how to solve

Re: B.3.1 The __proto__ pseudo property

On 23 April 2013 05:11, Mark S. Miller wrote: > The first two goals generally align well anyway. I think this is best served > by something that seems at least close to what was agreed on: > > * The syntax that we've already agreed to on this thread: {__proto__: } > is special syntax that init

Re: B.3.1 The __proto__ pseudo property

On 22 April 2013 22:15, Allen Wirfs-Brock wrote: > We don't currently have the concept of an object "belonging" to a realm. > Functions have a realm association, but not non-function object. I thought the current plan of record is to require this check for reflected uses of protosetter.call? So

Re: B.3.1 The __proto__ pseudo property

At least this one is minor: On Mon, Apr 22, 2013 at 8:11 PM, Mark S. Miller wrote: [...] > > { getter: [[ProtoGetter]], setter: [[ProtoSetter]], enumerable: false, > configurable: true } > Should be { get: [[ProtoGetter]], set: [[ProtoSetter]], enumerable: false, configurable: true } --

Re: B.3.1 The __proto__ pseudo property

OMG. I omitted the most important constraint: On Mon, Apr 22, 2013 at 8:11 PM, Mark S. Miller wrote: [...] > * Normal objects have a [[SetPrototype]] method like > > function [[SetPrototype]] (newValue) { > // normal checks for proto acceptability > // * either null or an ob

Re: B.3.1 The __proto__ pseudo property

Ok, I have read more messages on this thread and looked at some of the supporting material that has been pointed at. The notes from the last meeting record a conversation before I arrived, and I'm not quite clear what it says was agreed on. In any case, I think the primary goals should be and seem

Re: B.3.1 The __proto__ pseudo property

On Mon, Apr 22, 2013 at 1:15 PM, Allen Wirfs-Brock wrote: > We don't currently have the concept of an object "belonging" to a realm. > Functions have a realm association, but not non-function object. > The current idea on how to solve the security issue with weak references (and AFAIK the only s

Re: B.3.1 The __proto__ pseudo property

then what's the point to poison Object.getOwnPropertyDescriptor(Object.prototype, "__proto__").set if anyone can always use __proto__ to change the chain ? I don't understand this poisoning ... I don't see any advantage, only problems if some library would like to drop __proto__ and use in edge ca

Re: B.3.1 The __proto__ pseudo property

We don't currently have the concept of an object "belonging" to a realm. Functions have a realm association, but not non-function object. Object.create(parent);//we have no way to determine if parent "belongs" to the same realm as Object.create. we also currently have no way to determine wh

Re: B.3.1 The __proto__ pseudo property

On 22 April 2013 15:49, Brendan Eich wrote: >> However, in that case, I actually think that there is no need to have >> any special poisoning semantics when reflecting __proto__ -- mainly >> because the cross-realm check is already necessary in the unreflected >> case: you can construct an object

Re: B.3.1 The __proto__ pseudo property

Andreas Rossberg wrote: I have difficulties catching up with everything that has been said in this thread, my apologies if I repeat parts of the discussion. Here is what I thought we agreed upon earlier: 1. __proto__ is an accessor property on Object.prototype 2. reflecting it via Object.getOwnP

Re: B.3.1 The __proto__ pseudo property

I have difficulties catching up with everything that has been said in this thread, my apologies if I repeat parts of the discussion. Here is what I thought we agreed upon earlier: 1. __proto__ is an accessor property on Object.prototype 2. reflecting it via Object.getOwnPropertyDescriptor gives yo

Re: B.3.1 The __proto__ pseudo property

Mark Miller wrote: On Sun, Apr 21, 2013 at 9:42 PM, Brendan Eich > wrote: Ok, so (after pushing back based on recorded consensus, which I think is fair), I'm ok with * Object.prototype.__proto__ is configurable. * o = {__proto__: p} semantics changes

Re: B.3.1 The __proto__ pseudo property

oh dear ... var protoSetter = Object.getOwnPropertyDescriptor( Object.prototype, '__proto__' ).set; // < forgot the setter in previous example On Sun, Apr 21, 2013 at 10:07 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > right now this is the V8 situation: > https://code.goo

Re: B.3.1 The __proto__ pseudo property

right now this is the V8 situation: https://code.google.com/p/v8/issues/detail?id=2645 which is different from SpiderMonkey one where you can: var protoSetter = Object.getOwnPropertyDescriptor( Object.prototype, '__proto__' ); delete Object.prototype.__proto__; // optionally var a = {}, b = {}

Re: B.3.1 The __proto__ pseudo property

On Sun, Apr 21, 2013 at 9:56 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > if Object.getPrototypeOf() works there, how is that secret protected? > Assuming the script does not make the object that the literal evaluates to available to the hostile environment it is running it. This

Re: B.3.1 The __proto__ pseudo property

if Object.getPrototypeOf() works there, how is that secret protected? In any case, do you agree since you can configure Object.prototype.__proto__ you could also poison it by your own instead of proposing an unusable poisoned setter as it is now in V8? I am talking about this possibility (already

Re: B.3.1 The __proto__ pseudo property

On Sun, Apr 21, 2013 at 9:42 PM, Brendan Eich wrote: > Ok, so (after pushing back based on recorded consensus, which I think is > fair), I'm ok with > > * Object.prototype.__proto__ is configurable. > > * o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's > [[SetInheritance]]. > > I

Re: B.3.1 The __proto__ pseudo property

On Sun, Apr 21, 2013 at 8:45 PM, Brendan Eich wrote: > Andrea may be asking for less than the standard someday removing > __proto__, if I read him right. He's asking not to keep it > "indestructible", i.e., to make > > delete Object.prototype.__proto__ > > remove all the magic, including for 'o

Re: B.3.1 The __proto__ pseudo property

Ok, so (after pushing back based on recorded consensus, which I think is fair), I'm ok with * Object.prototype.__proto__ is configurable. * o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's [[SetInheritance]]. I'm not sure everyone agrees, but let's assume these two. Why, giv

Re: B.3.1 The __proto__ pseudo property

yep, I was asking to make it neutral 100% but that specific case, as written many replies before not only by me, seems to be reasonable, as long as delete Object.prototype.__proto__ is possible and, if this is possible, hoping that Object.getOwnPropertyDescriptor(Object.prototype, '__proto__').set

Re: B.3.1 The __proto__ pseudo property

On Sun, Apr 21, 2013 at 8:41 PM, Brendan Eich wrote: > So as my last post said, if there's no observable difference in the field > in switching from [[Put]] to [[SetInheritance]], then you and Mark are > right, and we can do that in ES6 without fear of breaking any code. > > This change *is* obse

Re: B.3.1 The __proto__ pseudo property

Again, you're inventing something new. Always risky, ignoring the throw-up-in-mouth effect :-|. Now the burden is on someone (who?) to find code on the web that uses the quoted form expecting the same results as the unquoted form, which is what all implementations I know of indeed provide. W

Re: B.3.1 The __proto__ pseudo property

Andrea may be asking for less than the standard someday removing __proto__, if I read him right. He's asking not to keep it "indestructible", i.e., to make delete Object.prototype.__proto__ remove all the magic, including for 'o = {__proto__: p}'. But that seems to require using [[Put]] rat

  1   2   >