New paper: "Distributed Electronic Rights in JavaScript"

Kevin Reid kpreid at google.com
Tue Jan 15 13:14:29 PST 2013


On Tue, Jan 15, 2013 at 12:49 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 15/01/2013 19:19, Kevin Reid a écrit :
>
>  From a capability viewpoint, there are non-performance reasons to have
> the same pattern, even within a given event loop, namely resources which
> may be transferred with observably exclusive access (ownership); the
> pattern is to have an operation on the resource which generates a new
> reference to it (i.e. a new object, from the OO perspective) and makes the
> old one useless ("revoked").
>
> Interesting. It reminds me that JavaScript does not have a notion of
> internal and external code with regard to an object. Anyone with access to
> the object can equivalently modify it (add, delete properties for instance).
> On object can't at the same time defend its integrity and modify its own
> shape (I guess it's possible with proxies now).
>
> I don't know why anyone would want to do that, but if you want to model a
> caterpillar becoming a butterfly, it's a bit complicated in JavaScript
> without proxies. The caterpillar has a "crawl" method and if we want the
> same object (same identity) to eventually become a butterfly with a "fly"
> method (but no crawl method), the object has to remain extensible and the
> crawl property has to be configurable.
>

Becoming useless is different from becoming a different interface; all that
is necessary is that the operations on the object are disabled. A simple
generic answer would be something like 'all getters return undefined, all
setters and methods throw'. Note that this is a change in the behavior of
functions and is therefore allowed to be entirely internal.

However, it is useful to have an application-specific notion of “useless”.
For a made-up-on-the-spot example, suppose the disabled object is some kind
of container; if it reports itself as being empty and only throws in
response to operations attempting to add new elements, then an application
may be able to avoid special-case code by letting the empty container be
handled as a trivial case rather than the caller of the transfer operation
having to make sure the container is removed from other places. Or consider
that objects for e.g. streams and open-files may be _closed_: anything that
designates an external resource often has some kind of well-defined useless
state.

Where have you seen the "create new object from old one" pattern used? It
> sounds interesting, but I can't think of where I'd use it.


Real examples are hard to find because (1) hardly anyone is writing ocap
code with detailed mutually-suspicious interactions, and (2) one generally
prefers to avoid having to manage exclusive access by not having a need for
exclusion (i.e. everyone has their own independent instance of whatever)!

Our canonical example of exclusive access is virtual money: money held in a
'purse' object may be exclusively transferred away by depositing it into a
new purse, leaving the old one with a balance of zero. (In this case, the
old object simply has a zero balance and may be reused.) Similarly, a
virtual board/card game could handle transfers between players of its
virtual 'physical' tokens this way.

If my examples are unconvincing, I leave it to MarkM to provide better ones
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130115/b45f04dd/attachment-0001.html>


More information about the es-discuss mailing list