Catch-all proposal based on proxies

Tom Van Cutsem tomvc at google.com
Tue Dec 8 11:40:06 PST 2009


On Tue, Dec 8, 2009 at 10:35 AM, Mike Wilson <mikewse at hotmail.com> wrote:

>  I certainly see the logic in your proposal, but I am uncertain whether
> the obj-proxy split is what the world wants, and what kind of up-take it
> would get among script authors? My impression is that the success
> of existing catch-all mechanisms is partly due to their perceived
> simplicity. The proposed design adds extra verbocity and handling
> for authors, needing to coordinate two different objects (of different type)
> instead of one that has been augmented, and to be careful about who has what
> reference.
>

It is true that the proxy API is slightly more complex than, for instance,
the __noSuchMethod__ trap in Spidermonkey. I cannot predict the up-take of
such an API, but it is worth mentioning that a simple noSuchMethod-like API
can be built on top of the proposal, in a library, without losing the
benefits of stratification. One possibility is to define a method named
"Object.createHandled", similar to ES5's "Object.create" method, but which
allows an additional noSuchMethod trap to be specified:

Object.createHandled = function(super, objDesc, noSuchMethod) {
  var handler = {
    get: function(rcvr, p) {
      return function() {
        var args = [].slice.call(arguments, 0);
        return noSuchMethod.call(this, p, args);
      };
    }
  };
  var p = Proxy.create(handler, super);
  return Object.create(p, objDesc);
};

Given a convenience function Object.getOwnProperties(obj), one could write:

Object.createHandled(Parent,
  Object.getOwnProperties({ ... }),
  function (id, args) { ... });

This comes close to the __noSuchMethod__-style of trapping missing methods,
without giving up on stratification (the 'noSuchMethod' trap itself is still
clearly separated from the object itself). The fact that an object literal
is passed as an argument to 'Object.getOwnProperties' is part of the idiom.
It ensures that the rest of the application only refers to the 'trapped'
object, and there is no need for the programmer to explicitly distinguish
the 'trapped' object from the 'non-trapped' object.


>  A somewhat related example of the "world's choice" is how third-party
> byte-code patching techniques have become the default choice in the Java
> community, instead of the standard Java proxies (java.lang.reflect.Proxy),
> which is a similar construct to the one proposed.
>

I cannot speak authoritatively about Java proxies, but one cause of this
evolution might be that Java Proxies only work for interface types. Hence,
anyone that wants to build a general wrapping/trapping mechanism that works
on any Java class is forced to abandon the Proxy abstraction and look for
other means to accomplish that goal.

Or are you seeing openings for syntactic sugar up the road, with classes
> etc?
>

Syntactic sugar is always a possibility, but with the introduction of ES5's
Object.* meta-methods, I think many abstractions can be built on top of
proxies as plain library abstractions.

Regards,
Tom


>
> Best regards
> Mike Wilson
>
> Tom Van Cutsem wrote:
>
> Dear all,
>
> Over the past few weeks, MarkM and myself have been working on a proposal
> for catch-alls for ES-Harmony based on proxies. I just uploaded a strawman
> proposal to the wiki:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:proxies
>
> Any feedback is more than welcome. Note that the proposal is quite lengthy,
> which is mostly due to the fact that it also includes a detailed semantic
> specification of proxies (in ES5-spec-style) in addition to just its API
> description. If you're not interested in the specification details, you can
> skip the section named "Semantics".
>
> Cheers,
> Tom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091208/30fe549e/attachment.html>


More information about the es-discuss mailing list