[cap-talk] Can Capabilities be configured?

[Tom Van Cutsem]

>
> So: how do we avoid ambient authority when mixing advice and
> metaprogramming with ocaps? Should individual objects have their own
> associated advice/metaprogramming functions that can be removed, or
> would this defeat the point of advice/metaprogramming? This is similar
> to a recent thread asking how to support debug logs, where these two
> mechanisms are common approaches to achieving it.


The work that Mark Miller and I have been doing recently on Ecmascript
Harmony Proxies <http://wiki.ecmascript.org/doku.php?id=harmony:proxies> seems
relevant.
It supports metaprogramming of special 'proxy' objects. To create a proxy,
you pass a 'handler' object to a proxy constructor. The constructor then
returns a proxy that allows the handler to intercept every operation applied
to said proxy (e.g. accessing a property, assigning a property, ...).

This is very much in the spirit of mirror-based reflection: proxy and
handler are cleanly separated ('stratified' is the term that Bracha and
Ungar use in their mirrors paper). Furthermore, I think it supports good
ocap programming patterns because an object can't get a reference to the
handler if it only has a reference to the proxy.

The fact that the mechanism only allows you to modify the behavior of
proxies, and not that of regular objects, ensures that the integrity of
regular objects is never jeopardized. Proxies, on the other hand, willfully
submit to being controlled by the handler specified by their creator.

If by 'advice' you mean the term as it's used in AOP/AspectJ, it's always
possible to construct a proxy/handler-pair where the handler defines an API
that allows its clients to, for example, register functions to be executed
before/after/around a method invocation on the proxy.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100407/61d46051/attachment.html