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. 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. 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? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
