Re: Proxies: get+fn vs. invoke

2010-10-27 Thread Dmitry A. Soshnikov
On 26.10.2010 11:41, Tom Van Cutsem wrote: 2010/10/25 Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com On Oct 25, 2010, at 12:35 PM, Tom Van Cutsem wrote: 2010/10/20 Dmitry A. Soshnikov dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com Anyway, is

Re: Proxies: get+fn vs. invoke

2010-10-27 Thread Dmitry A. Soshnikov
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

2010-10-25 Thread Tom Van Cutsem
2010/10/20 Dmitry A. Soshnikov dmitry.soshni...@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

Re: Proxies: get+fn vs. invoke

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

Re: Proxies: get+fn vs. invoke

2010-10-25 Thread Dmitry A. Soshnikov
On 25.10.2010 23:35, Tom Van Cutsem wrote: 2010/10/20 Dmitry A. Soshnikov dmitry.soshni...@gmail.com mailto:dmitry.soshni...@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

Re: Proxies: get+fn vs. invoke

2010-10-20 Thread Mark S. Miller
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

Re: Proxies: get+fn vs. invoke

2010-10-20 Thread Brendan Eich
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 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

Re: Proxies: get+fn vs. invoke

2010-10-18 Thread Dmitry A. Soshnikov
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

Re: Proxies: get+fn vs. invoke

2010-10-15 Thread Dmitry A. Soshnikov
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

2010-10-14 Thread Dmitry A. Soshnikov
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

2010-10-14 Thread Brendan Eich
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. Because

Re: Proxies: get+fn vs. invoke

2010-10-14 Thread Dmitry A. Soshnikov
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

Re: Proxies: get+fn vs. invoke

2010-10-13 Thread Dmitry A. Soshnikov
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

Re: Proxies: get+fn vs. invoke

2010-10-13 Thread Dmitry A. Soshnikov
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

Re: Proxies: get+fn vs. invoke

2010-10-13 Thread Brendan Eich
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

Re: Proxies: get+fn vs. invoke

2010-10-11 Thread Tom Van Cutsem
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

2010-10-11 Thread Dmitry A. Soshnikov
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

2010-10-11 Thread Dmitry A. Soshnikov
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