Direct proxies update

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Nov 27 16:07:25 PST 2011


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 <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)
> 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.  In fact, on my to do it, is to extend jsmirros to do so for accessing objects in web workers.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111128/30953bdb/attachment.html>


More information about the es-discuss mailing list