On Behalf Of Jonathan S. Shapiro While I have raised the topic on a couple of occasions, I have tried very hard to resist introducing [single] inheritance into BitC. I've avoided this for several reasons: 1. OO features are build around the "object" notion - which is to say: "state plus interface". That in turn tends to drive us fairly hard in the direction of a stateful language, which is a bias that I had hoped to avoid. 2. The question of when to use inheritance and when to use type classes seems challenging to answer. I wanted to avoid having confusingly similar ideas in the initial language. If nothing else, I wanted to avoid this for me. As a personal matter, OO idioms are very familiar, and I found myself reaching for them at the wrong times. Taken in combination with [1], this is a hazard to pure programming. 3. There are some typing issues around the notion of a "this" pointer that I had hoped to dodge. I don't think these are terribly difficult, but they exist, and it's one more thing to do. 4. Inheritance entails subtyping, which is problematic for inference. 5. The problem of const classes, and the resulting need to overload on const-ness, was a nagging problem. 1 & 2 are especially bad.. And yet, several issues seem to keep dragging me back in the direction of single inheritance plus interfaces. The current (incomplete) "capsule" mechanism is a constrained form of inheritance. Closed type classes can also be seen as providing an inheritance-like mechanism. In the end, I think that there is a pragmatically overwhelming reason to incorporate single inheritance and interfaces into BitC: immediate utility. There are simply too many libraries out there that we need to be able to use that are framed in terms of classical OO. I am certainly not proposing to eliminate type classes if we can make them work pragmatically. I also anticipate including the "interface" notion without the implicit downcast capability. Interfaces in languages that don't support multiple inheritance are used as the main form of multiple inheritance, what is the impact of having only explicit down cast ? Finally, I anticipate providing a means to generate interfaces as an extended form of procedure object; effectively a collection of procedures closed over the same state pointer (a very simple extension of the current Interface idea that is conspicuously missing in most languages). Reactions and thoughts? Inheritance has been a bane in large projects I worked on , they are over used and as the code grows they can become monstrous and difficult to refactor. While most good programmers use them well many bad programmers use them poorly and IMHO this is a big price. Interfaces on the other hand are easier to maintain and used better and can do everything inheritance can ( and more !) with one exception and that is when creating a struct (object?) that implements the interface you need to manually hook up shared code - However this is easier in a functional languages and is handled by type classes . So while strange for the sake of better maintenance I suggest interfaces but not inheritance.This should mostly resolve point 1 & 2 above. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
