On Wed, Jul 2, 2014 at 3:36 PM, Matt Oliveri <[email protected]> wrote:
> 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? > Yes. But since we appear to have fundamentally different understandings of the term "object", I'm not sure I agree. Ironically, I used to take the view that the object was the state, and there might be many organizations of behavior acting on that state. That's the view in which downcast and upcast don't change the object. I held this view because in KeyKOS/EROS/Coyotos you can end up with multiple capabilities to the same process that have very different effects on the "object" presented by that process. From the human standpoint, the thing that you can mentally "point" to is the blob of state, so it's conversationally natural to think of that as the object. The definition "object = state + behavior" is kind of unnatural conversationally when you start having interfaces. Incidentally: KeyKOS/EROS/Coyotos is an example of a system that has objects without inheritance. Capabilities conceptually denote interfaces. In EROS and Coyotos, interface signatures are defined by IDL, and interfaces can be extend (be derived from) other interfaces. At least in the OS context, I haven't found that interface inheritance has introduced any problems. It's hard to know if this is because interface and implementation are so strictly separated, or merely because we didn't proceed far enough to hit problems. > > 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. Yes. I was just being pedantic, and I don't think it was productive. I *do* think that we need to settle on common understandings of the terms "object" and "interface" for BitC, though. Let me take that up in my next message. > 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. OK. What you are saying makes sense to me now, but I find the terminology very confusing. Partly because I don't see this as a static/dynamic relationship. I see it as a type/inhabitant relationship. But even more because the word "dynamic" has all sorts of associations when we are talking about types, and those associations seem unrelated to what you are saying. I don't have a better term to suggest. I'm just trying to articulate why this is likely to continue to throw me off so that we can both be aware of the possibility of disconnect. > 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. Huh? I want some of what you're smoking. Oh. Perhaps what you are saying is that all of the operations are actually there, on the object, to be called (the dynamic interface), but that some of them may not be reachable through a particular interface or at some given superclass type. Is that what you are saying? If that's so, then no, I think that you *really* have this mixed up. It's *exactly* the ability to present a restricted subset of function that constitutes the ability to capture different authorities. If the language imposes promiscuous downcast or existential elim, then what you say is of course correct in the end. I prefer to think of that as a fundamental flaw in the language design rather than a property of cast. I think we're on the same page here, and we're debating where to attach this concept of authority in our respective lexicons of language concepts. > 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. > Yes and no. Yes to what you say about wrappers, but more generally, *any* operation that gets you from one "perspective" on an object to a different "perspective" having a different API is central to controlling authority. The notable exception being when the effect is a strict reduction on the original authority. > I see how what I said was ambiguous. English is lousy at this. > Well, yeah. But if it were easy, *anyone* could do it, right? :-) > > 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? > No. I was being pedantic. I meant only that the Java notion of "object" is not exactly "object = state + behavior". Note that when I say "impure" I don't mean to say that it's necessarily "bad". > > 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. This is a very fundamental place where we disagree. And not to be obnoxious, but (nyah nyah) you're wrong! :-) OK. Kidding aside. I actually *do* think you have this wrong. Yes, at bottom, there is a complete set of possible object behaviors (what you seem to mean by dynamic interface). But the ones that I can actually *exercise* are constrained by the static type through which I invoke. This means that the static type describes what part of the dynamic interface I have the authority to invoke. Which is *exactly* what we mean by authority. Actually, the right term here is "permission", not "authority". Authority is the transitive reflexive closure of reachable permission. > > 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. Perhaps. But if so, we should be going on the abstraction that the language *provides*, not to be confused with what the manual *documents*. Java interface objects really are wrappers > 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. > Yes. But in this case the implementation details make it clear that they *are* wrappers. There are other possible implementations, but they are semantically equivalent to the separate VTable implementation. Which is to say that all of them are semantically equivalent to wrappers. > I guess the question then is: Is BitC going to have a > notion of dynamic interface distinct from the static type? > No. BitC will not. Ah! (Light dawns). The dynamic interface you speak of is completely exposed by run-time introspection! I finally think I see why this is important in your mind. Add promiscuous introspection to the list of things that is profoundly wrong in Java and .NET. It's okay to have parts of the surface syntax that are helpful "sugar", like private/protected/public. The problem is that it's too easy to confuse those for having some real protective or encapsulative value. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
