On Wed, Jul 2, 2014 at 11:48 AM, Jonathan S. Shapiro <[email protected]> wrote:
> On Tue, Jul 1, 2014 at 4:55 PM, Matt Oliveri <[email protected]> wrote: >> >> But even so, they're not regular wrappers since they share the object >> id of the thing they wrap, or so I thought. > > > I don't recall saying that, but it's certainly not my intention. An > interface and the object it wraps are logically distinct objects. Downcast > should be thought of as an existential "open" operation on the encapsulated > thing. > Well that's even more different than Java than I realized then, because a downcast in Java definitely gives you the same object, I just double-checked. But in that case, then I agree that your version of downcast can only sensibly be thought of as unwrapping. Maybe it shouldn't even be called a cast. So it still seems >> like under your proposal, capabilities effectively become (static >> type, object) pairs. Maybe that's the right way to do it with a strong >> type system, but maybe not. >> > > That's what capabilities have always been. The classic formulation is that > a capability combines the authority to perform operations with a designator > to the state on which those operations act. When translated into PL terms, > "authority" is essentially "the list of methods". > Right, but on JVM at least, there's really two lists of methods for an object reference. The statically known ones from the type, and the ones it actually handles. In Joe-E they stuck with the dynamic method list as the notion of authority provided by a reference. So it's not like having static types forces you to change the notion of capability from what it is in a dynamic language. So "which method list" is a different way of stating the same design decision. However, since your downcast really is unwrapping, it doesn't matter in your case since both method lists change. > 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. >> >> That point of view would make type theorists very happy, but again, I >> don't think it's the point of view of most programmers. Changing the >> type isn't actually changing the thing, conceptually, so downcast is >> just a workaround for missing static information. > > > That is, and always has been, a wrong understanding. I'm certainly not > going to hold BitC to backwards compatibility with a foundational security > flaw. > I hope it isn't too wrong, because that's actually how I think about Java's type system. When the object id and all the object state are not affected by a downcast, what good is it to think of it as more than just a check, regardless of how it's implemented? I don't yet see what the >> additional complexity of your proposal provides for the programmer. > > > I think that's because you haven't had an opportunity to program in > capability systems that have a secure de-encapsulation mechanism. > You mean because getting to use an interface as a wrapper would be so much more convenient than making wrappers by hand? Yeah, now that I see that interfaces are wrappers, I think you're doing downcast right. I'm a little worried that you don't have what I would call interfaces, but you've thought about it longer than I have.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
