On Tue, Jul 1, 2014 at 3:10 PM, Jonathan S. Shapiro <[email protected]> wrote: > 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.
With the guard system you are proposing, is there anything about support for casts that isn't syntactic sugar on top of standard methods? The guard features you mention seem to work equally well for non-cast methods. If so, do we need sugar at all? Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
