Proxies: get+fn vs. invoke

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Thu Oct 14 14:32:36 PDT 2010


  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 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.

Well, if "on the premise" -- what can I say? -- then the main task is to 
find the solutions and fix all broken invariants.
> 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.
>

Of course. I'm absolutely not against if the missed methods will be real 
functions. Of course it's not per se that I want phantoms. "Phantoms" 
are just acceptable "implementation tax" to avoid all mentioned broken 
invariants. The tax is -- there are no funargs/apply. The tax is less 
than in case of broken invariants.

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

It's not versus. As I already mentioned and repeat it again -- I'd like 
to have noSuchMethod _in addition_  to other methods of a proxy handler 
(but not instead of proxies) . It still the proxies, just have 
additional method which handles (I repeat again) -- the _case_, the 
_situation_ of missing a property (this is how it's possible to justify 
phantoms -- the user deals not with a method, but with a _fact_, with 
the _situation_ of missing; And to handle this situation, he has a hook; 
from this viewpoint, possibly the user does not need a function itself).

But of course, if it's possible to have at the same time real functions 
and avoid broken invariants -- it'd be the best way. If there will be 
broken invariants -- no one needs such implementation. If it will be 
needed to write a huge code just to have noSuchMethod -- no one will be 
glad. Of course, if this huge code of fixing broken invariants will be 
abstracted and encapsulated from a user, then it's OK. But it's not.

So of course, I think that additional noSuchMethod will be simpler. And 
simplicity/shortness of the code  is one of the main features.

>> 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.)
>
>

Oh, I see.

>> . 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,

But (once again) I do not propose use _just_ noSuchMethod. I propose it 
as _addition_. And I already repeated not once -- still the _whole 
scheme with get+fn is still here_. We may even write a best-practice 
note that there should be used this and that (get+fn), with describing 
all the cases, with providing codes for caching/invalidating 
cache/deleting/etc. And near, just a small note -- "or, if you don't 
need funargs, you may use noSuchMethod hook of a proxy" (without 
promoting, without even examples, without everything, just a small note, 
that this hook is). And the we'll see what users will choose mostly.

> 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.
>

Yes, true. But repeat, we have to solve all broken invariants if on the 
premise there should no be _additional_ noSuchMethod hook for proxy 
handlers.

> This is something we should agree or disagree on before going further.

I see (and described before) current pros and cons of both approaches. 
With my approach we have first+second, with first -- only first. Of 
course I agree that it'd be good to have them as funargs. But if the 
price is -- inconvenience and broken invariants -- I choose not to use 
missed funargs then.

Still: try to see on it not as using a function (there is no function! 
it's missed), but as _handling the situation_ (the situation of missed 
method). Then noSuchMethod is quite logical hook.

>   Plus, I'm out of time to reply to the rest of your lengthy message. More when I can,
>

Unfortunately, me too. I'll answer on Tom's and your second letter later 
(today is already night here, going to seep). I read them, glad that 
some broken invariants became more clear after the detailed explanation 
and glad to see some code for handling it. But still I need to clear 
some things, so we'll do later.

Dmitry.

> /be



More information about the es-discuss mailing list