Le 28/11/2011 01:07, Allen Wirfs-Brock a écrit : > > On Nov 26, 2011, at 11:52 AM, David Bruant wrote: > >> 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)? > > Did you look at my blog posts and the jsmirrors code. It includes an > example of using a common mirror API to access both local objects and > a serialized external object representation. such an representation > can easily be used to access live remote objects. I agree, but I don't understand how you can use the same API for both local and remote objects. Or maybe you don't (retrieve representation async-ly and create the mirror when the representation is here)?
> In fact, on my to do it, is to extend jsmirros to do so for accessing > objects in web workers. I'm looking forward to seeing your implementation. David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
