Direct proxies update

[Tom Van Cutsem]

2011/11/24 Allen Wirfs-Brock <allen at wirfs-brock.com>

>
> If we are going to have a @reflection module that is of broader
> applicability then just writing proxy handlers I'd  like us to consider a
> Mirrors style API.  Otherwise I'm a concern will continue to have a
> proliferation of reflection APIs as we move beyond Proxies into other use
> cases.
>

I'm not sure I understand. Additional reflection functionality can easily
be added to the @reflect module. It need not be exclusive to Proxies.


> At https://github.com/allenwb/jsmirrors is a first cut of a mirrors API
> that I threw together earlier this year for JavaScript.  I don't hold it up
> as a finished product but it could be a starting point for this sort of
> design.
>

> At the core is a root question whether we want to expose a functional or
> object-oriented API for reflection functionality.  These are two different
> styles each of which is probably favored by a different subset of our user
> community.  I suspect that everyone knows which sub-community I align with.
> The main argument for the OO style is that it allows creation of client
> code that can be oblivious to the underlying implementation of the API.
>  The allows for more flexible client code that has greater potential for
> reuse.
>

I'm sympathetic to mirror-based APIs myself. However, note that a
mirror-based API would require an extra allocation as opposed to the
proposed API:

// Proposed API:
Reflect.has(object, name)

// Mirror-style API:
Mirror.on(object).has(name)

In the common case of forwarding an intercepted operation to a target
object, a mirror API requires the allocation of a mirror on the target,
just to be able to invoke the proper method, only for that mirror to be
discarded right away.

I don't see mirrors as being in conflict with this API though. Mirrors can
be perfectly layered on top.


> I haven't pushed for adopting mirrors into ES.next because I thought we
> already had too much on the table.  However, if we are going to create new
> reflection APIs then I think we should carefully consider the pros and cons
> of the mirrors style.
>

I don't understand why you think of the @reflect module as a "new"
reflection API: all of the functionality in it (save for the
VirtualHandler) was already present in the original Proxy proposal, where
most of the Reflect.* methods were methods on the default
ForwardingHandler. Putting them in a separate @reflect module seems the
right thing to do now that we have a module system.

I'm sympathetic to mirrors, but I don't think it's an either/or story. A
mirror-based API can be layered on top of the standard @reflect module. I'm
not sure it needs to be standardized now though: the current API provides
the minimum required functionality with minimum overhead.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111124/91b9062b/attachment-0001.html>