Proxies: get+fn vs. invoke

Dmitry A. Soshnikov dmitry.soshnikov at
Mon Oct 11 07:57:08 PDT 2010

  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 

OK, here is original letter sent before (the main question is not in 
"magic methods" directly on object, it's just a academic curiosity, but 
the main question is -- how in one /get/ method of the handler to manage 
missing properties and missing methods?) :

-------- Original message -----


I continue experiments with proxies (the first one was delegation-based 
mixins). Currently (only for academic curiosity) I've implemented 
objects with "magic hooks" which are defined "directly" on the objects. 
Actually, it's just a "proxied proxies", and there is no much sense in 
it (except maybe that such objects syntactically are shorter than real 
proxies), but repeat, the reason is -- only an academic interest of how 
do Proxy objects work. The script is here:

But this letter is not about the script (the script is just a reason), 
but about Proxy objects themselves. I'd like to clarify some features.

First, unfortunately, because of stratification of 
/Proxy.create(handler, proto)/ and /Proxy.createFunction(handler, 
callTrap, constructTrap)/ I can't manage in my "sugar" /typeof/ and 
/[[Class]]/ of a proxy object (depending on presence of /__call__/ or 
/__construct__/ -- in one case /typeof/ should result "function", in 
other case, if I later remove both /__call__/ and /__construct__/, it'd 
nice to have "object"). Yes, it's quit clear that it's related with 
/Function.prototype/ which is (should be?) set as a prototype of the 
function proxy. This question is not so essential, because I understand 
that the proxy strawman's idea assumes that a user will work with 
proxies, but not with directly defined (not stratified from an object) 
meta-methods, so I just mention this fact (that it turned out 
inconvenient for my script) :) Although, possibly someone will want to 
use this Python's "fancy" /__name__/s "sugar".

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 invariant with call/apply 
methods applied for the method:

var foo = proxy.nonExistingMethod;

Thus, /foo/ is a real function and also /proxy.nonExistingMethod()/ is 
the same as /

However, I don't see how can I implement a generic /get/ method in the 
proxy handler? I.e. I'd like to trap at the same time both: reading 
simple properties and also invocation of methods. In my script these 
are: /__get__/ (traps reading of all properties), /__noSuchProperty__/ 
(traps reading only of missing properties) and /__noSuchMethod__/ (traps 
methods invocations).

Of course, /get/ method of the handler may return (possibly creating 
every time new) a function and then we have 
/__noSuchMethod__/implementation. That's OK (having this approach we 
have "funargs + call/apply" scheme). But unfortunately, we can't 
distinguish what contains a call-site:

Is it a property reading:

or possible invocation:

How should /get/ trap of the proxy be implemented to support both: 
/__noSuchProperty__/ and /__noSuchMethod__/ ? This is the main question. 
Seems, there is no obvious way.

On the other hand, regating "funargs + call/apply" scheme: if the /get/ 
trap returns each time a new function, then === invariant is broken. 
That means it should return some predefined function from available for 
handling function-table (i.e. if name is "foo" -- return, 
etc). It of course can dynamically define the function and save it in 
the table. And actually to keep === invariant, it should do so.


-------- End of original message -----

> 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 --; I don't know
>     what again with es-archive server, but it doesn't display the
>     lettter which I send about "get+fn vs. invoke"
>     -- --
>     there only answer on the letter with correcting the typo).
> Hmm, your API defines all the handler methods directly on the object, 
> thus explicitly ignoring the stratification afforded by the original 
> API. Granted, your implementation filters out magic properties in 
> appropriate places, so they won't show up in e.g. for-in loops, but 
> the magic methods are still easily accessible directly from the 
> object. I understand that people just want to write:
> myObject.__get__ = function() { ... }
> instead of:
> var handler = Proxy.noopHandler(myOriginalObject);
> handler.get = function() { ... }
> myObject = Proxy.create(handler, Object.getPrototypeOf(myOriginalObject));
> I agree that the current API is too bulky if all you want is 
> __noSuchMethod__, but I'd much rather see a wrapper library that 
> allows me to write something like this:
> var [myObject, handler] = wrap(myOriginalObject);
> handler.get = function() { ... }
> or just:
> var myObject = wrap(myOriginalObject, { get: function() { ... } })
> This still keeps all the meta-functionality of an object in a separate 
> object. Code that only has access to "myObject" can't mess around with 
> its meta-level behavior. 'magic' methods don't prevent a client from 
> inadvertently overriding an object's traps.

Yes, everything correct with stratification of the meta- and normal- 
levels; I know that this is the main reason. As I said (and repeat it 
again) -- my implementation with __Ugly?PythonsNames__ is just an 
academic curiosity -- to play with proxies. And was playing with them, I 
backed to the ideological dilemma which was mentioned also several 
times: "get + fn vs. noSuchMethod/invoke". This is what Brendan 
mentioned before and also in the last slides of the recent JS Conf (I 
saw only slides, I didn't see yet video of Brendan's talk -- maybe he 
already answered this question? However, I didn't find the answer in 

The main (42? ;)) question is: how having /one get/ method in a proxy's 
handler to handle both cases of a call-site -- a /property reading/ and 
a /method invocation/ ?


Currently I understand, that implementation of the __noSuchMethod__ 
described in the strawman article is just wrong -- because /get/ method 
of the handler /always/ returns a /function/. That means, / - is 
a function, /foo.baz/, /foo.whatTheHack/ - is also a function. How a 
user will differentiate accesses to a non-function properties to a 
function properties?

Returning a function approach has advantages:

1. returned method can be extracted as a functional object (and e.g. 
passed as a funarg);
2. we have working call/apply invariant, i.e. is

But what if the user wants to trap get for non-existing /properties/ and 
non-existing /functions/? Here e.g. /get/ function from my implementation:

* generic [[Get]]
handler.get = function (r, name) {

   // __get__ hook
   if ("__get__" in object) {

   // if a property is not found
   if ("__noSuchProperty__" in object && !(name in object)) {
     return object.__noSuchProperty__(name);

   // here I don't know how to handle a method call-site

   return object[name];
};;  // __get__ bar
foo.nonExisting;  // __get__ nonExisting, __noSuchProperty__ nonExisting
foo.baz(); // __get__ baz
foo.nonExisting(); // *HOW CAN I MANAGE IT?*

I don't know what a call-site contains -- a function invocation or a 
property reading, so I can't in one get return a function or a property.

There can be /invoke/ trap which traps /all/ invocations:; // __invoke__ bar
foo.nonExisting(); // __invoke__ bar

But then it will be hard to distinguish it from /get/ which returns a 

On the other hand, there can be not /invoke/, but /noSuchMethod/ 
(/methodMissing/, /doesNotUnderstan/ -- call it as you wish) -- /exactly 
method/, i.e. a /TypeError "not a function"/. Then we can combine both: 
get+fn and noSuchMethod:

get: function (r, name) {
   if (name == "bar") {
     return function () {};
   return object[name];

then we have:; // function
proxy.baz; // object.baz; // OK -- get + fn -> call
proxy.nonExisting() // fail, get+undefined -> call: TypeError "not a 

And exactly the last case can be trapped with noSuchMethod. I can even 
implement it in my script (e.g. catching onError with debugger service, 
or even simple window.onerror -- though will be hard with arguments). 
But it can be additional trap for a proxy:

noSuchMethod: function (name, args) {
   console.log(name, args);


proxy.nonExisting(1, 2, 3); // get "nonExisting" -> call-site contains 
call expression -> noSuchMethod("nonExisting", [1, 2, 3])

The issues are also known:

proxy.nonExisting(1, 2, 3); is not the same as 
proxy.nonExisting.apply(null, [1, 2, 3]) and we can't extract 
proxy.nonExisting as a function ('cause obviously it's not a function). 
But what is more convenient for a user -- to catch such methods or to 
keep invariants with apply/funargs? Also, as I mentioned, even if it is 
done via get, then /to keep === invariant/, get should return always the 
same missing function for a property (which means to keep some dispatch 
table). So, anyway, some invariants will be lost anyway (or will be 
complex/inconvenient in implementation) and it's needed to choose what 
is better for a user. I think it will be good to have additionally for 
proxies noSuchMethod trap.


>     Maybe you can answer on this question regarding proxies? How can
>     we handler in one get of a proxy handler both cases of a call-site:
>     and
>     ? 
>     Having invoke, we handler However, the case when
>     the get returns should look (unfortunatelly?) like (
>     Also of course does not extracted as a functional object
>     (including invariants But I think, is it the
>     case that user wants to used them exactly as funargs or he wants
>     more to handle just access (exactly calling of) to non-existing
>     methods? P.S.: to avoid off-topic regarding this topic devoted to
>     traits/mixins, it's better to answer to that trhead -- "get+fn vs.
>     invoke".
> 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 detect get+call vs 
> invoke, but it turned out that not all implementations would be able 
> to support it: 
> <>
> In retrospect it may not be so bad that this feature isn't supported. 
> I can imagine it could lead people to write code like:
> get: function(receiver, name, args) {
>   // suppose that args === undefined implies that the property was 
> only queried, not invoked
>   if (args === undefined || args.length === 0) {
>     return 'a';
>   } else {
>     ...
>   }
> }
> So that <> and <>() 
> would both return 'a'. This could lead to a lot of confusion, since 
> it's hard to quantify what " <>" denotes. If 
> it's supposed to be a method, then <> should 
> return a function. If it's supposed to be a getter, then 
> <>() should call the thing returned by the getter 
> (which, in this case, should raise a type error since strings are not 
> callable)
> Cheers,
> Tom
> 2010/10/9 Dmitry A. Soshnikov <dmitry.soshnikov at 
> <mailto:dmitry.soshnikov at>>
>     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.
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list