[E-Lang] Rights Amplification: The Next Layer Up
Dean Tribble
tribble@netcom.com
Wed, 06 Sep 2000 00:16:59 -0700
First, a general reaction: If you pursue this syntax, I will personally
add your name to all the spam mailing lists. So there! :-)
A "facet" is a separate capability with an independent authority (and
typically a different interface) on the same "object". In the Mint
example, the 'decr' and 'purse' are facets of the same "object"
(http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money).
E syntax of course does facets implicitly by having multiple definitions in
a shared scope, but nonetheless they are facets.
Facets are *not* a dispatch mechanism for single methods that you might or
might not be able to access.
Facets are *not* typically about meta-level access.
Facets are *not* typically all accessible through a particular (even
primary) facet of the object.
Facets are *not* going to improve my sleep tonight, so I will desist at
three, and hope I don't have to find all those darn spam lists....
>The key observation (from Joule's "Energetic Secrets"
>ftp://ftp.webcom.com/pub1/agorics/postscript/MANUAL.B17.ps.Z ) is 1) as
>mentioned earlier, a brand identity can be treated like a message name,
>identifying the semantics of a request, and 2) therefore dispatching on
>brand-match is like dispatching on message name. Seen this way, our
>standard objects dispatch on both message names (actually message name +
>arity) and on brands. The syntactic sugar can suggest this view:
>
> define objName {
> to msgName1(params1...) :retType1 { methodExpr1 }
> to msgName2(params2...) :retType2 { methodExpr2 }
> ...
> facet (sealerExpr1) => (facetExpr1)
> facet (sealerExpr2) => (facetExpr2)
> ...
> match pattern1 { matcherExpr1 }
> match pattern2 { matcherExpr2 }
> ...
> }