On Wed, Jul 2, 2014 at 3:48 PM, Jonathan S. Shapiro <[email protected]> wrote: > But I would argue that downcast is a special case of opening in which the > underlying state pointer happens not to change.
Yes. That's a valid way to look at it. But in the presence of subtyping, I don't think it's the natural way to look at it. Did you see my idea to call this special case "inspect" in the absence of subtyping? > 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. Things are getting confusing. Let me summarize how I'm thinking about Java. Types, including interfaces, are a static approximation of the actual object interface, which is the set of public methods the object implements. (It's actually more than that, but lets not make things even more complicated.) That set is what I called the "dynamic interface". You can access all of it (and more, sadly) with the reflection API. It's this dynamic interface that I think of as influencing the authority granted by an object reference. Casts have no affect on the dynamic interface of an object, or which object you're using, and thus have nothing to do with authority. They are only bookkeeping for the current static approximation of the dynamic interface. Wrappers, on the other hand, give you a different object, probably with a different dynamic interface, so wrapping and unwrapping is central to controlling authority. >> 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'm not talking about static methods. I'm talking about types vs. the dynamic interface of an object, as described above. But in hindsight, I see how what I said was ambiguous. English is lousy at this. > I don't think we should be looking to Java as our exemplar of how to think > about this stuff properly. :-) Just that I thought Java came up with the thing that's called an interface type. But yeah, you're talking about something quite different. >> 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. You mean because it has non-object base types, with different cast semantics? I don't see how that's relevant, since they provide no authority. (From a pure capabilities point-of-view, not from a cryptographic one.) > But from the purist perspective object = state+behavior, downcast gets you a > new object because it gets you new behavior. No, the behavior of an object is accessed through its dynamic interface, which isn't affected by casts. You _could_ make your statement true by getting rid of any notion of dynamic interface entirely. No downcast, and no reflection. This is more like OCaml. But I actually find OCaml's object system to be extremely misguided. > 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. Sorry, I have no idea what you're saying here. >> 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. Yeah, I heard. It's a clever implementation technique, but we should be going on the abstraction that the language provides, not how it's implemented. All these implementation details tell us is that we're already paying for the overhead of wrappers, whether or not we obtain the afforded semantics. But you have a point, if wrappers are the right way to implement interfaces anyway, why would we deprive the programmer of the richer semantics? I guess the question then is: Is BitC going to have a notion of dynamic interface distinct from the static type? Even with your version of interfaces, it's still sound for a distinction to pop up someplace else. Wrapping and unwrapping change both the type and the dynamic interface, but some other operation might only change the type. Or reflection would ignore the type entirely. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
