On Tue, Jul 1, 2014 at 9:54 AM, Matt Oliveri <[email protected]> wrote:
> Are you thinking of types as capabilities or object references as > capabilities? Object references. > If object references, then casting should not be thought > of as affecting the authority provided by a reference. Nonsense! An upcast is authority reducing, and a downcast or a side-cast is authority enhancing. There is a chicken and egg problem here. The *reason* we don't consider these operations to be authority enhancing is that the authority to cast is unconstrained in the language design. Given the lack of constraints on cast, the ability to get the other objects is inherent in holding the first object, and then, yes, the operations should not be viewed as amplifying authority. And sometimes that's the behavior you *want*. But that behavior should not be dictated by the language design. There are use cases for interfaces that enable promiscuous cast, and use cases for interfaces that enable only "guarded" cast, and use cases for interfaces that enable no cast at all. And that's the reason that I'm introducing this discussion. If we do not assume within the language that downcast and sidecast are inherently unconstrained, we gain the ability to do certain kinds of secure encapsulation in the style of capability systems. I have always felt that it was a mistake in the design of Java and C# that holding an interface reference allowed you to obtain a reference to the underlying object. That should be an encapsulation boundary, or at least the developer should have the *option* to make it an encapsulation boundary. But you're proposing some weird > cross breed where a token object reference makes it OK to use > something at a different type. Why do you need that? I'm proposing something sneakier than that, because the guard requirement can be made by design to be something promiscuous like unit. That has the same effect as enabling promiscuous downcast. The reason you want *other* options is so you can do things like the sealer/unseal pattern. If you want to > use object references for authority, then an abstract type is not a > means to attenuate authority; for that you use a wrapper. At least > this is what I thought I learned about object-capability security. Is > the problem that the wrapper might be too much overhead? > But interfaces ARE wrappers! That's the point! Look at it this way: I could have done the "as(guard: T) -> Y" entirely without the help of any language idiom. That's essentially what you do with wrappers. What I'm saying is that downcast is a de-encapsulating operation, and de-encapsulating operations shouldn't be forced on the designer of the object. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
