2012/12/21 Allen Wirfs-Brock
>
> On Dec 21, 2012, at 7:01 AM, Tom Van Cutsem wrote:
>
> I think that with the provision of the Handler API, we provide Proxy
> authors with the same benefits than if we would add delegation to the ES6
> built-ins, without any required changes to existing internal m
On Dec 21, 2012, at 7:01 AM, Tom Van Cutsem wrote:
> 2012/12/21 Allen Wirfs-Brock
>
> On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
>
>> 2012/12/20 Allen Wirfs-Brock
>>
>> On Dec 20, 2012, at 2:21 AM, Tom Van Cutsem wrote:
>>> If target.baz is a writable data property
>>> proxy.baz = 4
On Dec 21, 2012, at 5:15 AM, Andreas Rossberg wrote:
> On 21 December 2012 03:00, Allen Wirfs-Brock wrote:
>
> On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
>> I'm not sure I follow. In my understanding, the original Receiver is only
>> needed for traps that involve prototype-chain walki
2012/12/21 Allen Wirfs-Brock
>
> On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
>
> 2012/12/20 Allen Wirfs-Brock
>
>>
>> On Dec 20, 2012, at 2:21 AM, Tom Van Cutsem wrote:
>>
>> If target.baz is a writable data property
>> proxy.baz = 42 will eventually call Object.defineProperty(proxy, 'ba
On 21 December 2012 03:00, Allen Wirfs-Brock wrote:
>
> On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
>
> I'm not sure I follow. In my understanding, the original Receiver is only
> needed for traps that involve prototype-chain walking and are thus
> |this|-sensitive. That would be just [[G
On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
> 2012/12/20 Allen Wirfs-Brock
>
> On Dec 20, 2012, at 2:21 AM, Tom Van Cutsem wrote:
>> If target.baz is a writable data property
>> proxy.baz = 42 will eventually call Object.defineProperty(proxy, 'baz',
>> {value:42})
>> (and *not* Object.
On Dec 20, 2012, at 12:12 PM, Tom Van Cutsem wrote:
> 2012/12/20 Allen Wirfs-Brock
> Yes, here is the new step 5 as I have just updated it in my spec. draft
> (ignore the 1, it's really 5)
> If IsDataDescriptor(ownDesc) is true, then
> If ownDesc.[[Writable]] is false, return false.
> If Type(
2012/12/20 Allen Wirfs-Brock
> Yes, here is the new step 5 as I have just updated it in my spec. draft
> (ignore the 1, it's really 5)
>
>1. If IsDataDescriptor(*ownDesc*) is *true*, then
> 1. If *ownDesc*.[[Writable]] is *false*, return *false*.
> 2. If Type(*Receiver*) is not Ob
2012/12/20 Allen Wirfs-Brock
>
> On Dec 20, 2012, at 2:21 AM, Tom Van Cutsem wrote:
>
> If target.baz is a writable data property
> proxy.baz = 42 will eventually call Object.defineProperty(proxy, 'baz',
> {value:42})
> (and *not* Object.defineProperty(proxy, 'baz',
> {value:42,enumerable:true,wr
below
On Dec 20, 2012, at 2:09 AM, Tom Van Cutsem wrote:
> [+jwalden]
>
> 2012/12/19 Allen Wirfs-Brock
> ...
>
> Currently, that test is performed in step 5.b. by testing whether the
> "current" object we are visiting in the proto chain O is the Receiver object.
> At first sight, this is a ra
On Dec 20, 2012, at 2:21 AM, Tom Van Cutsem wrote:
> 2012/12/19 Allen Wirfs-Brock
> If we make the Option A change that seems right for [[GetP]]/[[SetP]] then
> we will have an inconsistency between the this value used for a method
> invoked as proxy.foo() and a accessor invoked as proxy.bar
2012/12/20 Andreas Rossberg
> On 20 December 2012 11:09, Tom Van Cutsem wrote:
>
>> Currently, that test is performed in step 5.b. by testing whether the
>> "current" object we are visiting in the proto chain O is the Receiver
>> object. At first sight, this is a rather weird way of deciding bet
Le 20/12/2012 11:09, Tom Van Cutsem a écrit :
(...)
The right fix (at least, it feels like the obvious right fix to me),
is not to test whether O === Receiver, but rather just let the
algorithm explicitly test whether the Receiver object already defines
an own property with key P, to decide be
On 20 December 2012 11:09, Tom Van Cutsem wrote:
> Currently, that test is performed in step 5.b. by testing whether the
> "current" object we are visiting in the proto chain O is the Receiver
> object. At first sight, this is a rather weird way of deciding between
> update vs. addition. We can g
2012/12/19 Allen Wirfs-Brock
> If we make the Option A change that seems right for [[GetP]]/[[SetP]]
> then we will have an inconsistency between the this value used for a method
> invoked as proxy.foo() and a accessor invoked as proxy.bar
>
To clarify, if we apply the fix to [[SetP]] described
[+jwalden]
2012/12/19 Allen Wirfs-Brock
> Consider:
>
> let target = {foo() {return this}};
> let proxy = Proxy(target, {});
>
> As currently spec'ed. proxy.foo() is going to return proxy rather than
> target.
>
> That's because, proxy.foo evaluates to a Reference whose base is proxy.
> Getti
Andrea Giammarchi has pointed out in the past that it's not possible to
fully shim __noSuchMethod__ because of this same issue. Perhaps introducing
a [[CallProperty]] is not such a bad idea.
On Wednesday, December 19, 2012, Allen Wirfs-Brock wrote:
> I'm not sure there is an easy fix that doesn'
On Dec 19, 2012, at 2:01 AM, Tom Van Cutsem wrote:
> 2012/12/19 Allen Wirfs-Brock
> I think it has to be A, for consistency with [[Call]]. Note that when
> [[Call]] is directly forwarded to the target, the this value is set to
> target. It wouldn't be self-consistent if directly forwarded foo
2012/12/19 Andreas Rossberg
> So it has to be A. (Or the definition of Reflect.set has to change. I
> don't have much love for the case distinction in there anyway. But it's
> probably a necessary consequence of the somewhat incoherent property
> assignment model we are stuck with.)
>
Indeed. To
2012/12/19 Allen Wirfs-Brock
> I think it has to be A, for consistency with [[Call]]. Note that when
> [[Call]] is directly forwarded to the target, the this value is set to
> target. It wouldn't be self-consistent if directly forwarded foo.access and
> foo.method() invocations used different th
On 18 December 2012 22:56, Tom Van Cutsem wrote:
> Option B:
> Address point 2) directly by changing the test that determines property
> addition versus property update inside Reflect.set (i.e. the [[SetP]]
> internal method of objects) so that the algorithm no longer tests whether
> target === r
I think it has to be A, for consistency with [[Call]]. Note that when [[Call]]
is directly forwarded to the target, the this value is set to target. It
wouldn't be self-consistent if directly forwarded foo.access and foo.method()
invocations used different this values.
I assume that by "proxy
Hi,
Someone recently reported an issue [1] while using my harmony-reflect shim
for direct proxies. The fix probably requires a change in the proxy
specification. I'm unsure how to resolve it, so I thought I'd bring it to
the list.
The issue is as follows:
consider a proxy with an empty handler:
23 matches
Mail list logo
