Proxies: get+fn vs. invoke

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Mon Oct 25 13:28:23 PDT 2010


On 25.10.2010 23:35, Tom Van Cutsem wrote:
>
>
> 2010/10/20 Dmitry A. Soshnikov <dmitry.soshnikov at gmail.com 
> <mailto:dmitry.soshnikov at gmail.com>>
>
>     (I answer both -- Brendan's and Mark's letters for convenience in
>     here).
>
>
>     On 20.10.2010 21:06, Brendan Eich wrote:
>>     On Oct 20, 2010, at 9:16 AM, Mark S. Miller wrote:
>>
>>>     On Wed, Oct 20, 2010 at 7:10 AM, Dmitry A. Soshnikov
>>>     <dmitry.soshnikov at gmail.com <mailto:dmitry.soshnikov at gmail.com>>
>>>     wrote:
>>>
>>>         OK, I'd like nevertheless to continue the discussion with
>>>         possible decisions.
>>>
>>>         Here is a description of how [[Get]] method can work of a
>>>         trapping proxy object (I took the basis from the proxy
>>>         semantics page --
>>>         http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics#semantics_of_proxies):
>>>
>>>         [[Get]] (P)
>>>
>>>         When the [[Get]] internal method of a trapping proxy O is
>>>         called with property name P, the following steps are taken:
>>>
>>>            1. Let handler be the value of the [[Handler]] internal
>>>         property of O.
>>>            2. Let get be the result of calling the [[Get]] internal
>>>         method of handler with argument “get”.
>>>            3. If get is undefined, return the result of performing
>>>         the default behavior, by consulting handler’s
>>>         “getPropertyDescriptor” trap.
>>>            4. If IsCallable(get) is false, throw a TypeError exception.
>>>            5. Let getResult be the result of calling the [[Call]]
>>>         internal method of get providing handler as the this value,
>>>         O as the first argument and P as the second argument.
>>>            6. if getResult is undefined and [[HasProperty]](P)
>>>
>>
>>     [[HasProperty]] takes O as its receiver (this) parameter, so
>>     doesn't this break double-lifting?
>>     (http://wiki.ecmascript.org/doku.php?id=harmony:proxies#a_simple_membrane)
>>
>>
>
>     Hm.. Actually, I don't completely understand what is "double
>     lifting" (a proxied proxy?) as well as the whole membrane example
>     (to many wrap-wrap-wrap and a every time a creating of a new
>     function), but I think I should carefully read Mark's
>     "markm-thesis.pdf" paper. Though, your example from slides is
>     simpler than on the strawman page (but there too -- wrap calls
>     wrapFunction, which in turn calls wrap again -- not so easy to get
>     from the first glance, but I'll look closer).
>
>     However, if someone can clarify it (the main and basic idea in
>     "two words" and regarding "double lifting" too) I'll be very
>     thankful, 'cause it's interesting.
>
>     Anyway, is there an alternative how [[HasProperty]] can work
>     correctly? I just though, that it's called by the "has" hook of a
>     handler, which in turn can "lie" of course (i.e. return true when
>     a property does not exist -- in such a case, noSuchMethod won't be
>     called).
>
>
> I think Dmitry is right: calling [[HasProperty]] on a proxy object 
> should trigger its "has()" trap in the normal way, which should work 
> with double lifting.
>
> In short, double lifting is a trick where the handler object of a 
> proxy is itself a handler.

Ah, I see, thanks. I realized it too while was analyzing the membrane 
example from Brendan's slides.

> See section 4.5 of the paper about proxies that MarkM and I presented 
> at the Dynamic Languages Symposium last week (here's a link to the 
> submitted, non-final, version: 
> <http://soft.vub.ac.be/~tvcutsem/proxies/assets/proxies.pdf 
> <http://soft.vub.ac.be/%7Etvcutsem/proxies/assets/proxies.pdf>>) In 
> the paper, we use the term "meta-level shifting" instead of "double 
> lifting", but it's the same concept.
>

Yeah, I'll take a detail look on the document. Thanks.

P.S.: btw, I also realized that I misinterpreted (possibly a hardness of 
translation) your conclusion that there may be no sense in noSuchMethod. 
I missed your words about that a proxy may have no a proxied object 
(i.e. a handler just returns some completely virtual calculation dealing 
without any object). Apologize. So, from this viewpoint of course 
noSuchMethod looks a bit strange.

Taking into account this fact, possibly it's good to move availability 
of noSuchMethod to the minor task, since the major task are mentioned 
(in previous letters, and in the recent one to Brendan) issues -- with 
if (!o.foo) o.foo = {...}, etc. Since the transparency of proxy objects 
is a sound feature, a user of the proxy object shouldn't know that this 
is a proxy. And therefore he may use it as he/she wishes. But he won't 
be able, since `o.foo` will always be a function.

Also a mentioned by Mark approach with `isCall` flag will also require 
caching/invalidating the cache, etc. And unfortunately, as also was 
mentioned, it's a vicious circle -- if to distinguish call/not a call 
(via the flag e.g.) -- we, theoretically, do not have desirable virtual 
functional object, i.e. o.foo -- will be (possibly) `undefined` anyway 
(in other case -- for what to distinguish call/not a call?). And o.foo() 
will be called as a virtual function. That again leads to `only-invoke 
phantoms` scheme.

So, it's not a simple question, and there is more sense to think about 
issues, rather than about presence of noSuchMethod as itself.

By the way, do you see some/any solutions for those issues (Mark, 
Brendan)? I don't see yet.

Dmitry.

> Cheers,
> Tom
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101026/cb2d75d3/attachment-0001.html>


More information about the es-discuss mailing list