Direct proxies update

David Bruant bruant.d at gmail.com
Mon Nov 28 07:50:56 PST 2011


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 <allen at wirfs-brock.com
>>> <mailto: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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111128/fa796952/attachment.html>


More information about the es-discuss mailing list