[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 }
>          ...
>      }