On 25.10.2010 23:35, Tom Van Cutsem wrote:
2010/10/20 Dmitry A. Soshnikov <[email protected]
<mailto:[email protected]>>
(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
<[email protected] <mailto:[email protected]>>
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
