On Wed, Jul 2, 2014 at 11:47 AM, Matt Oliveri <[email protected]> wrote:
> 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. > I apologize. I'm going to stop using "downcast" for this from now on, because it was the wrong term and I keep misusing it. I agree that it shouldn't be called either "downcast" or "cast". The accepted name for opening an existential wrapper is "open". But I would argue that downcast is a special case of opening in which the underlying state pointer happens not to change. More radically: if we define "object" as state+behavior, then the ID of the same state at two interfaces should be different, even if the interfaces happen by accident to contain state pointers that are EQ. This actually gets us into the very old debate about EQ vs EQL vs EQUAL vs EGAL, which I really don't think we need to replicate here. Please note that I'm not proposing we should take this position. I'm just noting that it's the consistent position from a purist view of objects. I'm actually very up in the air about how object hashing should work in BitC. > 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. > That's just syntax. Ignoring the private/protected/public notion, static methods are just functions that have been strangely bundled into a peculiar namespace. I don't think we should be looking to Java as our exemplar of how to think about this stuff properly. :-) > > > 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? > The problem isn't with your understanding of Java. The problem is that Java implements an impure object model. Whether that's a problem in practical terms depends on which sides of which fences you stand on ideologically. But from the purist perspective object = state+behavior, downcast gets you a new object because it gets you new behavior. The more consistent terminology to have used for this would have been that interfaces are views on objects, but that breaks down when you admit interface inheritance. Once that goes in, Interfaces are just degenerate classes. 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. > Think about Java some more. Strip away the way that Interfaces are connected up to the syntax of Java (the "implements" thing), and ask what you get when you fetch an interface reference from an object reference. Peek under the covers and you'll discover that the two references don't have the same bits, and that the interface object actually has a distinct VTable from the one used by the object itself. This is necessarily true, because the respective VTables contain different methods. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
