On Tue, Jul 8, 2014 at 10:27 AM, Jonathan S. Shapiro <[email protected]> wrote: > 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. > > ... > > If it felt like I was shutting you down, I apologize. ... I > shouldn't take those frustrations out on you.
No don't worry, it didn't seem like that. I was just surprised you apologized like that over a small misunderstanding. (I don't even remember what it was now offhand.) I'm actually getting very tired of the discussion about dynamic interface vs. static interface as permissions. I've been trying to end the recent back and forth with Sandro without being rude. Basically I don't think you need to worry about dynamic interface as permissions in the near term because it's only helpful for programming styles with loads of dynamic type checks. (If even then. Sandro seems to believe my perspective is never useful.) >> > 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? > > 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. Right, that's what I was thinking. It seems like that's how you'd simulate C++ objects. (Not saying you'd want to most of the time.) > 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. Let me clarify by restating what I think you mean. - Interfaces would use record subtyping for the set of methods provided. - There is no notion of "virtual" because there's no class hierarchy. - However, interface methods are dynamically dispatched to whatever implementation is provided by an element of the type. (Via a vTable pointer.) - Functions that should not dynamically dispatch should not be interface methods. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
