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. Not entirely the main benefit of these methods is as an organization tool to group methods with the data they manipulate , having an implicit this compared to an explicit call is almost cosmetic , though obviously you then have the issues of public vs private vs internal visibility. I think we agree that there are few "sustainably" well-formed uses of implementation inheritance. Yes but I have noted in larger projects that maintenance programmers often get it wrong and will quickly reduce the quality of the code.. 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. I think this is what it comes down to eg public /private / internal permissioning vs a more pure / immutable approach . At present with bitc this is done more at the module level than the struct level. which suggests that inheritance/ interfaces should remove modules ( replace with namespaces) add public , private and internal . The question is where do you end up ? Almost C# with some better struct / immutable support 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. Yes I think this merits more thought and note an interface can still represent an object by grouping the functions for the struct to construct a quasi class and then explicitly stating which functions need access. In addition this quasi object can be mapped to the CLR . Does this also replace modules ? Shouldn't modules then be a larger interface ? Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
