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
