Le 24/11/2011 22:29, Tom Van Cutsem a écrit : > 2011/11/24 Allen Wirfs-Brock <al...@wirfs-brock.com > <mailto:al...@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) I have been thinking about this a lot and I don't find any advantage to "Mirror.on(object).*(...rest)" over "Reflect.*(object, ...rest)" ... for local objects. After reading http://bracha.org/mirrors.pdf , I have realized that the mirror API aims at more than providing reflection with a uniform API for other sorts of objects including, for instance, remote objects.
Unfortunately, I am not sure I can go further, because I haven't found a definition of what a remote object is and don't really know how reflecting on them differs from reflecting local objects. Among the questions: * What is a remote object? * How does it differ from a local object? * Do you need a local object to "emulate" a remote object? * Does reflecting on remote objects impose synchronisity (waiting for the remote object to "respond" before telling what the answer is)? > 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 agree this sounds like an overhead if the goal is to restrict the API to local objects, but if we want to use the same API for promises, it may be necessary. > 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 think that the difference is that the ForwardingHandler was limited by the restrictions imposed on proxies. The fact that the API is separated into a module decouples from this limitation enabling operations like Reflect.getPrototypeOf(object) or even Reflect.getClassString(object) which could not have been considered for the ForwardingHandler. > 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. Would it apply to promises the same way as well? David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
