Re: Proxies: get+fn vs. invoke

On 27.10.2010 21:15, Brendan Eich wrote: On Oct 27, 2010, at 9:07 AM, Tom Van Cutsem wrote: With the risk of going round the block again... ;-) Last time for sure. :-| Acknowledged ;| I agree with your premises, namely that: a) `if (!foo.bar) foo.bar = {}` is a common pattern to patch up

Re: Proxies: get+fn vs. invoke

On 26.10.2010 11:41, Tom Van Cutsem wrote: 2010/10/25 Brendan Eich mailto:bren...@mozilla.com>> On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote: 2010/10/20 Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> Anyway, is there an alternative how [[HasProperty]] can work

Re: Proxies: get+fn vs. invoke

2010/10/25 Brendan Eich > On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote: > > 2010/10/20 Dmitry A. Soshnikov > >> 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

Re: Proxies: get+fn vs. invoke

On 25.10.2010 23:35, Tom Van Cutsem wrote: 2010/10/20 Dmitry A. Soshnikov > (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

Re: Proxies: get+fn vs. invoke

On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote: > 2010/10/20 Dmitry A. Soshnikov > 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

Re: Proxies: get+fn vs. invoke

2010/10/20 Dmitry A. Soshnikov > (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.soshni...@gmail.com

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 b

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 semant

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_proxie

Re: Proxies: get+fn vs. invoke

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 int

Re: Proxies: get+fn vs. invoke

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. The point that Brendan and I seem to have converged to is that enabling *both* of them allows the creation of (meta-)programs with semanti

Re: Proxies: get+fn vs. invoke

On 14.10.2010 22:57, Tom Van Cutsem wrote: ... All do work. I.e. any missing property, for you, is a method. Do whatever you want with it. Call e.g. your noSuchMethod function inside it. - Hm, but how can I test whether a some method (or a property) exists on my object?

Re: Proxies: get+fn vs. invoke

On 14.10.2010 19:38, Brendan Eich wrote: On Oct 14, 2010, at 7:54 AM, Dmitry A. Soshnikov wrote: On 14.10.2010 4:14, Brendan Eich wrote: On Oct 13, 2010, at 6:56 AM, Dmitry A. Soshnikov wrote: Also I think now, that what was named as pros, i.e. ability to have funargs and call/apply invari

Re: Proxies: get+fn vs. invoke

On Oct 14, 2010, at 12:33 PM, Brendan Eich wrote: > Tom, thanks for this, assuming it is an accurate reading of Dmitry's post, > your reply clarifies something for me. When we bridged Java to JS in the > '90s, we had to deal with Java objects having overloaded members. A member > o.m could be a

Re: Proxies: get+fn vs. invoke

On Oct 14, 2010, at 11:57 AM, Tom Van Cutsem wrote: > It is, however, debatable whether it is appropriate to override `o.n` with > the external function just because it does not exist on o2. After all, the > proxy can handle missing methods. Presumably, the code in the else-branch is > going to

Re: Proxies: get+fn vs. invoke

> > ... All do work. I.e. any missing property, for you, is a method. Do > whatever you want with it. Call e.g. your noSuchMethod function inside it. > - Hm, but how can I test whether a some method (or a property) exists on my > object? > > Obviously, the approach: > > if (!o.n) { > o.n = functi

Re: Proxies: get+fn vs. invoke

On Oct 14, 2010, at 7:54 AM, Dmitry A. Soshnikov wrote: > On 14.10.2010 4:14, Brendan Eich wrote: >> >> On Oct 13, 2010, at 6:56 AM, Dmitry A. Soshnikov wrote: >> >>> Also I think now, that what was named as pros, i.e. ability to have funargs >>> and call/apply invariants, in real, not so pros.

Re: Proxies: get+fn vs. invoke

On 14.10.2010 4:14, Brendan Eich wrote: On Oct 13, 2010, at 6:56 AM, Dmitry A. Soshnikov wrote: Also I think now, that what was named as pros, i.e. ability to have funargs and call/apply invariants, in real, not so pros. Because users more likely want to catch exactly missing methods (if you

Re: Proxies: get+fn vs. invoke

On Oct 13, 2010, at 5:14 PM, Brendan Eich wrote: > Now consider if you had a third parameter to the 'get' trap to signal callee > context vs. non-callee context. You'd still want to proxy the functions, that > doesn't get simpler just due to a change of trap parameters. You'd still want > to ca

Re: Proxies: get+fn vs. invoke

On Oct 13, 2010, at 6:56 AM, Dmitry A. Soshnikov wrote: > Also I think now, that what was named as pros, i.e. ability to have funargs > and call/apply invariants, in real, not so pros. Because users more likely > want to catch exactly missing methods (if you don't like the word "methods", > sin

Re: Proxies: get+fn vs. invoke

On Oct 13, 2010, at 3:28 PM, Dmitry A. Soshnikov wrote: > I too. How do you think, would it be good to ask Oliver Hunt this question? https://bugs.webkit.org/show_bug.cgi?id=18058 is resolved WONTFIX. I have another reply under way that makes a strong case against __noSuchMethod__ (which I adde

Re: Proxies: get+fn vs. invoke

On 13.10.2010 23:33, Tom Van Cutsem wrote: Regarding this example with undefined args: I think you agree that correct check should test `arguments.length` to see whether `args` is here. However, as I mentioned, it may be more convenient to separate in own place, i.e. to the `noS

Re: Proxies: get+fn vs. invoke

> > Sorry, this part of your reply was formatted with a small text -- the same > as quote of my letter, so I completely lost it and didn't see at all. Just > saw it now in es-archive (there is no font size formatting). Actually, you > answered in this replay on the question I was asking in the next

Re: Proxies: get+fn vs. invoke

On 11.10.2010 18:18, Tom Van Cutsem wrote: In short: the 'get' trap can't distinguish the above two cases. This is a pity, and I agree it would be useful for 'get' to have that information sometimes. There has previously been talk on this list of parameterizing 'get' with an additional flag to

Re: Proxies: get+fn vs. invoke

On 11.10.2010 22:45, Tom Van Cutsem wrote: Where this proposal is described? I didn't see it. I'll support it. Even if the committee won't agree on noSuchMethod, it'd at least will be great to have a parametrized get. Though, repeat, IMO, a separated method for this case is bett

Re: Proxies: get+fn vs. invoke

> > Where this proposal is described? I didn't see it. I'll support it. Even if > the committee won't agree on noSuchMethod, it'd at least will be great to > have a parametrized get. Though, repeat, IMO, a separated method for this > case is better. > I think the thread starts here: < https://mail

Re: Proxies: get+fn vs. invoke

On 11.10.2010 20:07, Tom Van Cutsem wrote: The most interesting question for me is mentioned several times (the last one was by Brendan in his slides from the lates JS Conf) "get + defining Fn" vs. invoke trap. Yes, there are some cons: a non-existing method can be extracted

Re: Proxies: get+fn vs. invoke

> > The most interesting question for me is mentioned several times (the last > one was by Brendan in his slides from the lates JS Conf) "get + defining Fn" > vs. invoke trap. > > > Yes, there are some cons: a non-existing method can be extracted as a > funarg for later use. It also do not break in

Re: Proxies: get+fn vs. invoke

On 11.10.2010 18:18, Tom Van Cutsem wrote: This is odd, I didn't see the original message you were replying to. Yes, really odd. It's not the first time when the archive-server looses letters. OK, here is original letter sent before (the main question is not in "magic methods" directly on

Re: Proxies: get+fn vs. invoke

This is odd, I didn't see the original message you were replying to. To respond to the question you posed in the "syntax for efficient traits"-thread: Yes, I do. The latest is "magic methods" directly on objects (possibly you > saw -- http://gist.github.com/617338; I don't know what again with >

Re: Proxies: get+fn vs. invoke

On 10.10.2010 0:44, Dmitry A. Soshnikov wrote: Yes, there are some cons: a non-existing method can be extracted as a funarg for later use. It also do not break invariant with call/apply methods applied for the method: Sorry, typo, not cons, but pros of course. Dmitry. ___