that code is wrong and I don't know why or who would assume that accordingly with specs
I'd rather file a bug in there, pointing at specs ... there are two places about __proto__, everything else/other interpretations are evil indeed take care On Mon, May 5, 2014 at 6:48 PM, John Barton <johnjbar...@google.com> wrote: > Since you ask for a response: > > > On Mon, May 5, 2014 at 11:30 AM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> not sure I understand but ... >> >> > that makes no sense as hasProxyAsProto is not a Proxy >> >> it's inheriting from a Proxy so where is the surprise? it does what I'd >> expect it to do, pass through the inherited Proxy same as you pass through >> inherited get/set methods when creating from an object that has get/set >> behaviors >> > > I was incorrectly assuming that the proto chain would not be consulted for > __proto__: it would be found on every object. Boris' post described the > mechanism of __proto__, then I could see why the get operation traversed > the proto chain and thus why my proxy's getter was called. (IMO, having a > getter high on the proto chain that uses 'this' (receiver) to return values > only known to the 'this' object is pretty evil business, even among > notoriously dubious functions like getters.) > > May I suggest that trying to guess why someone is surprised is a better > strategy than telling them that you are not surprised. > > >> >> Moreover, since you inheriting a proxy that reacts on accessors you have >> the right behavior when you access `__proto__`, the `target.__proto__` >> should be returned instead. >> > > This makes no sense to me, sorry. Since `target` is already > obj.__proto__, target.__proto__ should not be returned. > > >> >> Last, but not least, `__proto__` is an `Object.prototype` property that >> has nothing to do with `Object.getPrototypeOf` .... you can redefine >> `__proto__` behavior either in the `Object.prototype` itself, through a >> proxy, or within an object, but that won't affect returned value of >> `Object.getPrototypeOf` >> > > Fine but not relevant: the code I am analyzing would, absent my proxy, > always give the same result for Object.getPrototypeOf and __proto__. Sure > these could be different, but in reality it doe not happen because too much > code relies on these being the same. > > >> ```javascript >> var o = {}; >> Object.defineProperty(o, '__proto__', { >> get: function () { >> return String.prototype; >> } >> }); >> >> o.__proto__ === String.prototype; >> Object.getPrototypeOf(o); // Object.prototype >> ``` >> >> Best Regards >> >> >> >> On Mon, May 5, 2014 at 10:40 AM, John Barton <johnjbar...@google.com>wrote: >> >>> I'm hoping someone can explain this result which surprises me. >>> >>> If I create an object with a Proxy-ed prototype, the resulting object >>> does not obey .__proto__ equal Object.getPrototypeOf(). >>> >>> For example: >>> var aPrototype = {foo: 'foo'}; >>> var handler = { >>> get: function(target, name, receiver) { >>> console.log(' (Proxy handler \'get\' called for name = ' + name + >>> ')'); >>> return target[name]; >>> } >>> }; >>> var aProxy = Proxy(aPrototype, handler); >>> var hasProxyAsProto = Object.create(aProxy); >>> >>> At this point, I expected >>> hasProxyAsProto.__proto__ === aProxy >>> but it it not true. Moreover, the operation >>> hasProxyAsProto.__proto__ >>> calls the Proxy handler get function with name === '__proto__': that >>> makes no sense as hasProxyAsProto is not a Proxy. >>> >>> I tried this on Firefox 29 and Chrome 36. Complete example is here: >>> https://gist.github.com/johnjbarton/f8a837104f0292fa088c >>> >>> Any ideas? >>> jjb >>> >>> _______________________________________________ >>> 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