Since a lot of people are responding negatively to inheritance, let me try to summarize where various threads of conversation have put us today, and what I see as the issues in inheritance vs. type classes.
We have already agreed that some form of member function notion is useful. A member function is one that is trusted to maintain the integrity constraints of a data structure. Note that the existence of member functions tacitly implies the notion of a "this" pointer. I think we agree that there are few "sustainably" well-formed uses of implementation inheritance. I think we agree that the notion of "interface" corresponds much better to the notion of "contracts" than inheritance does. I believe - and I *suspect* we will agree - that there are two substantive differences between interfaces and type classes: - An interface must be planned for by the developer of the object, because "this object implements interface I" is part of its declaration. This is not true of type classes. - An interface (at least in Java and C#) has an implicit "this" pointer, and its members can therefore have integrity-privileged access to the underlying object. This is not true of type class methods. To evaluate the difference more clearly, I propose that we "break" the strong tie between interfaces and objects. Let us instead define an interface as a collection of functions sharing a common (possibly empty) closure. This is mostly convenient because it lets us finesse the object/closure distinction for a moment, and it admits the possibility that interfaces might be constructed in post-hoc form.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
