[E-Lang] Rights Amplification: The Next Layer Up
Dean Tribble
tribble@netcom.com
Tue, 05 Sep 2000 23:51:36 -0700
At 05:30 PM 9/5/2000, Mark S. Miller wrote:
>[Dean, please read carefully. It's rather different than what we agreed on.]
>
> New Universal Method: getOptSealedFacet(brand)
How about getOptMeta? "Sealed" is just an implementation issue; the
purpose is to get meta-level access. It is also not necessarily a facet,
for example in the comm case, it returns a replacement object, which is
probably not a facet.
>We define one new universal method. When written without sugar, a method ...
> match ==(FooSealer brand) {
Is this really what "match" looks like?
> Uses
>
>...to return an object to be serialized in lieu of itself. The
>replaceObject()
>method of a given serialization stream may do:
>
> to replaceObject(original) :any {
> def optBox := original getOptSealedFacet(myUnsealer brand)
> if (optBox == null) {
> original
> } else {
> myUnsealer unseal(optBox)
> }
Should this be?
} else {
def rep := myUnsealer unseal(optBox)
if (rep == original) {
rep
} else {
replaceObject(rep)
}
}
>Of course the programmer normally wants the language implementation to
>magically take care of many meta-level issues for him. For example,
>PassByCopy objects should serialize their instance variables by default
>without the programmer needing to say anything further. Likewise for
>debugging, equality, and auditor verification. That's why getOptSealedFacet
>should default, not to returning null, but to
>
> match _ { meta getDefaultOptSealedFacet(self, brand) }
>
>"meta" is a keyword, and provides a syntactic escape for just such purposes.
> The E BNF just specifies that "meta" may be followed by a message as if
> you
>were synchronously calling it. However, the parsing actions dispatch on the
>message name & arity to enforce specific rules and create an expression
>parse node of a specific type. For getDefaultOptSealedFacet, the first
>"argument" must be the name of a lexically enclosing object definition.
This seems, um, inelegant... :-)
>This expression provides the default system-defined meta-level behavior
>for those cases not overridden by the programmer. This requires the TCB to
>have prior knowledge of certain sealers, which is fine. The object itself
>may
>not have access to some of these sealers, such as for equality, in which
>case it can only override requests with those brands to deny service.
>getDefaultOptSealedFacet() itself will default to returning null.
Why is this ever better than just returning null? Or rather why is this
not the default behavior when returning null? My only speculation is that
the meta-system would provide some access that the caller would otherwise
be unable to achieve with respect to this object. An alternative way to
accomplish that is using a function in the TCB that is closely held by the
appropriate meta subsystem. For comm, let's call it
getCommReplacement: getCommReplacement exclusively holds the
unsealer. The Comm system invokes getCommReplacement with the original
object. getCommReplacement first sends the getOptMeta request with the
brand, and if the result is not null, returns. If the result is null, it
returns whatever the "meta getDefaultOptSealedFacet(self, brand)" above
would have returned. That seems to cover all the issues, bogus clients
can't screw it up, it's much simpler to implement the overrides, and it is
probably easier to make efficient.
>Next: A Pinch of New Syntactic Sugar
>
>
>Many phone conversations with Dean and MarcS, and memories of Joule's
>"Energetic Secrets", contributed enormously to these ideas. Thanks!
Your welcome.