Re: Proxies: get+fn vs. invoke
On Oct 20, 2010, at 9:16 AM, Mark S. Miller wrote: > On Wed, Oct 20, 2010 at 7:10 AM, Dmitry A. Soshnikov > 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) > is false and [[Get]] is activated with production CallExpression : > MemberExpression Arguments then >6.a Let noSuchMethod be the result of calling the [[Get]] internal > method of handler with argument “noSuchMethod”. >6.b If IsCallable(noSuchMethod) is true then >6.b.I Let argList be the result of evaluating Arguments, producing > an internal list of argument values. >6.b.II Return the result of calling the [[Call]] internal method > of noSuchMethod providing handler as the this value, O as the first argument > and P as the second argument, argList as the third argument >7. Return getResult. Just because the handler's get trap returns undefined does not mean a noSuchMethod trap should be tried. A get trap returning undefined is the way to satisfy a get on a proxied property whose value happens to be undefined. > > Thoughts? Breaking double-lifting is a deal breaker. > > P.S.: And I want to ask to vote everyone on this list about whether this > additional hook for proxy handlers is needed. My voice is first -- "yes". This list is not set up for voting. It's not productive to try. Let's stick with technical issues such as breaking double-lifting. > > P.S.[2] In case of "no", we should back to all broken invariants and find the > solutions. Dmitry: I'm not sure what you mean here. > I vote "no", but I do have some sympathy for some of the goals. The only > proposal along these lines I've seen that I like[*] is to provide an > additional flag parameter to the get trap. When false, or if the get trap > ignores the flag parameter, everything operates as in the current Proxies > proposal. When a method call is performed on a proxy, (proxy.name(args) or > proxy[expr](args)), then the get trap is invoked with the flag set to true. > Given that a handler is only accessible from proxies, when a handler's get > trap is invoked with the flag set to true, the following invariants are > guaranteed: > > * The value returned by the get trap will be [[Call]]ed with its this binding > will be identical to the rcvr parameter of the get trap. > * The value returned by the get trap will only be [[Call]]ed, and will not > otherwise escape. > > IIRC, this proposal died on overhead it would impose on non-proxy calls on > JSC. As the JSC implementation evolves, perhaps this constraint may ease. > Let's keep our eyes open. But if not, I still vote "no". I bet V8 peeps would object as well, but let's hear from them directly if possible. > [*] I forget from who. If someone knows, please post. Thanks. IIRC the third parameter to the get trap, telling whether get trapped from a callee context, was from Dmitry. /be > > > > P.S.[3]: I understand that the committee discussed it before (as Brendan > mentioned). But as we saw, _the things have changed_ and we have many holes > in the only scheme "get+fn". So in addition to this scheme it will be good to > JS has noSuchMethod hook for proxies. Thus, if the "get" will return a > function, the complete scheme "get+fn" is still working (and we get right the > step 7 after 6), i.e. we lose nothing, but gain in addition a convenient hook > which avoids broken invariants. And since the things have changed, I think > the decision (even it was already discussed some-when before) should be > reconsidered too. > > Thanks, > Dmitry. > > > > On 18.10.2010 12:25, Dmitry A. Soshnikov wrote: >> >> On 18.10.2010 8:30, Tom Van Cutsem wrote: >>> >>> I understand you are arguing for noSuchMethod in addition to the existing >>> get trap, and I think we a
Re: Harmony and globals
This is discussed in the simple modules spec: http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules The top of the scope chain would not be a global *object* but there would still be global bindings. One of the things on my to-do list is to create a strawman for where all the standard libraries would live. Presumably, the stuff that is in the initial global object in <= ES5 would be in scope by default, ie in the initial environment. So undefined, isNaN, Array, String, etc would still be accessible through the usual means. Dave On Oct 20, 2010, at 8:43 AM, Peter van der Zee wrote: > In the other thread it was mentioned that Harmony would not have global at > the top of the scope chain. Was that pulled out of context or is that > something planned for any code as long as you're in Harmony? Because if it > is, I'm wondering about the semantics of built-in globals like undefined, > isNaN and the built-in objects (Array, String, etc). > > - peter > ___ > 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
Re: Proxies: get+fn vs. invoke
On Wed, Oct 20, 2010 at 7:10 AM, Dmitry A. Soshnikov < dmitry.soshni...@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) is false and [[Get]] > is activated with production CallExpression : MemberExpression Arguments > then >6.a Let noSuchMethod be the result of calling the [[Get]] internal > method of handler with argument “noSuchMethod”. >6.b If IsCallable(noSuchMethod) is true then >6.b.I Let argList be the result of evaluating Arguments, > producing an internal list of argument values. >6.b.II Return the result of calling the [[Call]] internal method > of noSuchMethod providing handler as the this value, O as the first argument > and P as the second argument, argList as the third argument >7. Return getResult. > > Thoughts? > > P.S.: And I want to ask to vote everyone on this list about whether this > additional hook for proxy handlers is needed. My voice is first -- "yes". > > P.S.[2] In case of "no", we should back to all broken invariants and find > the solutions. > I vote "no", but I do have some sympathy for some of the goals. The only proposal along these lines I've seen that I like[*] is to provide an additional flag parameter to the get trap. When false, or if the get trap ignores the flag parameter, everything operates as in the current Proxies proposal. When a method call is performed on a proxy, (proxy.name(args) or proxy[expr](args)), then the get trap is invoked with the flag set to true. Given that a handler is only accessible from proxies, when a handler's get trap is invoked with the flag set to true, the following invariants are guaranteed: * The value returned by the get trap will be [[Call]]ed with its this binding will be identical to the rcvr parameter of the get trap. * The value returned by the get trap will only be [[Call]]ed, and will not otherwise escape. IIRC, this proposal died on overhead it would impose on non-proxy calls on JSC. As the JSC implementation evolves, perhaps this constraint may ease. Let's keep our eyes open. But if not, I still vote "no". [*] I forget from who. If someone knows, please post. Thanks. > > P.S.[3]: I understand that the committee discussed it before (as Brendan > mentioned). But as we saw, _the things have changed_ and we have many holes > in the only scheme "get+fn". So in addition to this scheme it will be good > to JS has noSuchMethod hook for proxies. Thus, if the "get" will return a > function, the complete scheme "get+fn" is still working (and we get right > the step 7 after 6), i.e. we lose nothing, but gain in addition a convenient > hook which avoids broken invariants. And since the things have changed, I > think the decision (even it was already discussed some-when before) should > be reconsidered too. > > Thanks, > Dmitry. > > > > On 18.10.2010 12:25, Dmitry A. Soshnikov wrote: > > On 18.10.2010 8:30, Tom Van Cutsem wrote: > > I understand you are arguing for noSuchMethod in addition to the existing > get trap, and I think we all agree that proxies could support both get + > noSuchMethod. > > > Yes. At least that already all agree is a progress. I glad to hear it, > since I'm also interested in the JS design and want to have it convenient > and elegant in it's abilities (how is that was?: "Languages are tools, they > should evolve to serve their users", for what I add -- but not to bother > their users with undetermined results in respect of broken invariants). > > The point that Brendan and I seem to have converged to is that enabling > *both* of them allows the creation of (meta-)programs with semantics that > we'd rather avoid (the ability to create invoke-only methods). > > > Tom, I specially described several times (and in the recent letter -- > described in detail) the conceptual difference between these two approaches. > Once again, try to see on it from the _notifying_ a hook about the missing > method _event_, but not working with some mystic "non-e
Harmony and globals
In the other thread it was mentioned that Harmony would not have global at the top of the scope chain. Was that pulled out of context or is that something planned for any code as long as you're in Harmony? Because if it is, I'm wondering about the semantics of built-in globals like undefined, isNaN and the built-in objects (Array, String, etc). - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies: get+fn vs. invoke
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) is false and
[[Get]] is activated with production CallExpression : MemberExpression
Arguments then
6.a Let noSuchMethod be the result of calling the [[Get]]
internal method of handler with argument "noSuchMethod".
6.b If IsCallable(noSuchMethod) is true then
6.b.I Let argList be the result of evaluating Arguments,
producing an internal list of argument values.
6.b.II Return the result of calling the [[Call]] internal
method of noSuchMethod providing handler as the this value, O as the
first argument and P as the second argument, argList as the third argument
7. Return getResult.
Thoughts?
P.S.: And I want to ask to vote everyone on this list about whether this
additional hook for proxy handlers is needed. My voice is first -- "yes".
P.S.[2] In case of "no", we should back to all broken invariants and
find the solutions.
P.S.[3]: I understand that the committee discussed it before (as Brendan
mentioned). But as we saw, _the things have changed_ and we have many
holes in the only scheme "get+fn". So in addition to this scheme it will
be good to JS has noSuchMethod hook for proxies. Thus, if the "get" will
return a function, the complete scheme "get+fn" is still working (and we
get right the step 7 after 6), i.e. we lose nothing, but gain in
addition a convenient hook which avoids broken invariants. And since the
things have changed, I think the decision (even it was already discussed
some-when before) should be reconsidered too.
Thanks,
Dmitry.
On 18.10.2010 12:25, Dmitry A. Soshnikov wrote:
On 18.10.2010 8:30, Tom Van Cutsem wrote:
I understand you are arguing for noSuchMethod in addition to the
existing get trap, and I think we all agree that proxies could
support both get + noSuchMethod.
Yes. At least that already all agree is a progress. I glad to hear it,
since I'm also interested in the JS design and want to have it
convenient and elegant in it's abilities (how is that was?: "Languages
are tools, they should evolve to serve their users", for what I add --
but not to bother their users with undetermined results in respect of
broken invariants).
The point that Brendan and I seem to have converged to is that
enabling *both* of them allows the creation of (meta-)programs with
semantics that we'd rather avoid (the ability to create invoke-only
methods).
Tom, I specially described several times (and in the recent letter --
described in detail) the conceptual difference between these two
approaches. Once again, try to see on it from the _notifying_ a hook
about the missing method _event_, but not working with some mystic
"non-existing" (but which actually always exists) method.
I repeat once again:
function handleNoSuchMethodEven(base, name, args) {
console.log(name, args);
}
if (typeof foo.bar != "function") {
handleNoSuchMethodEven(foo, "bar", [1, 2, 3]);
}
if (typeof foo.baz != "function") {
handleNoSuchMethodEven(foo, "baz", [4, 5, 6]);
}
And for not to repeat every time this desugared code, this hook should
be added. But notice, that we deal with just a _check for presence_.
Still `foo.bar` and `foo.baz` as were before `undefined` properties
(i.e. *really* non-existing "methods"), so far they stay the same --
correctly `undefined` after the check applied and the handler is
called. Thus, all invariants are working.
Also, let me notice, still, I'm not asking to add the hook. I propose
to add the hook with providing sound arguments. And still, since I'm
interested in the JS design and want to see it logical and with some
convenient powerful tools which will "serve their users", I logically
insist on adding this hook. Then we'll have both schemes.
Besides the committee which I'll ask to vote (considering the _current
state_ of proxies i.e. considering all the issues I found during was
playing with proxies), I can bring a huge "army" of JS programmers
(the users for whic
