On Sun, Jul 6, 2014 at 8:24 PM, Matt Oliveri <[email protected]> wrote:
> On Sun, Jul 6, 2014 at 8:29 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > Very sorry. > > Don't be. It's your project, and if I'm just making it more difficult > it's my fault. > Matt: Please don't think about it that way. It took me a while to understand what you were saying about Java, but once I did the discussion turned out to be very useful. It's important to know where we stand relative to other approaches for a long list of reasons, not least that it lets us learn more clearly from their successes and failures. You're very good at holding a position and writing as its advocate. It's something I really appreciate about you. The fact is: we *need* some sand in the gears in these discussions. It keeps us honest. If it felt like I was shutting you down, I apologize. I've been distracted this week for personal reasons, and also trying to wrap up some code that has been resisting me so that I can get back to the compiler proper. I shouldn't take those frustrations out on you. > > > There is one field, which is the existentially encapsulated data > > that is accessible to all methods. > > But the concrete type of that field could be anything, including a > unboxed tuple with multiple things. Is that what you're saying? > The binding of the existential datum itself shouldn't be mutable for a bunch of reasons (lots of race conditions possible if it is, among other things), but that datum can certainly contain mutable fields. Whether it can be unboxed remains to be seen. My intuition says that we want that to be possible, because there's really no point adding another indirection given that interfaces don't necessarily wrap anything. I don't recall any issue offhand that would *preclude* an unboxed datum, but I have an itchy feeling that I can't crystalize at the moment. Does that help? > > >> OK, but then why would you _want_ to use interfaces instead of objects? > > > > Perhaps because we don't have objects in the C++/Java/C# sense, or > because > > we don't have inheritance and thus need facets. > > Ah that must be it. I was assuming this was some mostly redundant > object-like thing, but this _is_ the object-like thing! You're not > calling it an object in order to think of the object as the state > blob, like you could with OSes, I presume. > > And by no inheritance, you mean no implementation inheritance as well > as no subtyping, right? I certainly mean no implementation inheritence. If we admit subtyping into the language, then interfaces are one of the places where subtyping should be possible. The thing we will *not* do in that case is anything like virtual methods. So it's more like extending the structure than subclassing. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
