OK. I think I can now state what has made me uncomfortable about the Oliveira class notion. I do not say that I *should* be uncomfortable; only that I can now say what has been itching at me. In brief: the Oliveira classes (O-classes) are *too* abstracted. They correspond far better to Java/C# Interfaces than to conventional classes. Interfaces are a fine thing to have, but they are an insufficient answer for BitC.
If you start from a C++ background, it seems very natural to ask: shouldn't classes subsume structures/records, and it seems natural that the answer to this should "obviously" be yes. O-classes do not have this subsumption property, and in consequence, they will carry a high runtime performance overhead. An O-class defines a dictionary, so in general its "methods" must be invoked through a dictionary with the associated costs of that invocation. More problematic, an O-class has no fields, so simple getters and setters have prohibitive cost. Outside of special cases (which, importantly, include the constraint-style cases), this overhead cannot be statically compiled out. A hotspot-style VM can certainly eliminate a lot (perhaps most) of this overhead, but one firm design objective for BitC is that we not undertake the assurance challenges of requiring JIT compilation. Allow it yes, require it no. This brings me to the following question: why not let classes have fields just as structures do? Then divide "methods" into BitC-style methods (which are mere syntactic sugar) and overridable methods (which are O-class methods). Offhand, I don't see any reason why the resulting classes would fail to subsume typeclasses just as O-classes do. If we now introduce single inheritance, then O-class object defintions simply become derived classes. Note that a class of this form is certainly not required to have fields or non-overridable methods. This appears to subsume O-classes. I see no reason why we cannot incorporate a notion of an implicit class or a sealed class, though I am not immediately convinced that sealing the classes is necessary to support pattern matching. I'm going to let this roll around in my head a bit longer and try to capture it more carefully later today. I'm a bit disgusted that I seem to have mangled Oliveira's ideas back into exactly the sort of C++/C#/Java style of object system that we all have negative feelings about... If we were starting over, I'ld really prefer interfaces and interface inheritance. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
