Proxies: get+fn vs. invoke

Brendan Eich brendan at mozilla.com
Thu Oct 14 08:38:04 PDT 2010


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 users more likely want to catch exactly missing methods (if you don't like the word "methods", since there're no methods, there are properties, let's say -- missing properties which ended with `call expression` at the call-site).
>> 
>> That's not our experience with E4X (ECMA-357), which specifies XML methods as invoke-only. They seem to be normal function-valued properties of XML.prototype, but getting one by name on an XML instance in a non-callee expression context instead tries to find an XML child element or elements of the method's name, returned as a list.
>> 
>> Some of this is peculiar to E4X, but the invoke-only nature of the methods, per-spec, is not. And it breaks apply and functional programming, so we extended E4X with the function:: pseudo-namespace to allow one to extract methods from XML instances.
>> 
> 
> Yes, I'm aware of it. However, you mention a similar end result (inability to extract a function with a normal (accessor) syntax), but with completely different reason. In case of EX4 you talk about the existing real methods. In case of proxies, we talk about non-existing property (which is activated with a next call expression).

Stop right there -- I think you are assuming you conclusion, or favored outcome.

For proxies we want users to reify real function objects (or function proxies which are equivalent). Not reify nothing on get, making the methods invoke-only phantoms. We are disagreeing on the premise that invoke-only methods are better.

It seems to me you favored invoke-only methods because the code to implememnt them (using __noSuchMethod__, an invoke trap, or even a get third argument telling context) was "simpler". Not because you wanted invoke-only methods _per se_. Please clarify.

I do not think invoke-only methods are a feature in any case, ignoring implementation costs of __noSuchMethod__ vs. Proxies.


> The difference is: in first case a user really deals with existing stuff and expect the functions to be extracted (of course in this case ECMA-357 had to do something --  provide :: -- to allow this)

(No, that was our function:: extension -- E4X leaves these XML prototype methods invoke-only on XML instances.)


> . In the later one, at the first place, a user wants to catch the call expression.

Does the user really want *only* this? Or might it be "simpler" to hack with __noSuchMethod__, but the user would ideally want get to reify a function that could be passed around, invoked later, etc.?

I argue the latter is what users want if they think about it, or get to the point of purveying their invoke-only methods to most JS hackers, who do use partial application (apply via a helper function on a funarg), and so forth. Prototype, JQuery, etc. are full of such code. It will break badly on invoke-only methods.

This is something we should agree or disagree on before going further. Plus, I'm out of time to reply to the rest of your lengthy message. More when I can,

/be


More information about the es-discuss mailing list