Glynn Clements
The class hierarchy is only really relevant if you're writing new widgets [...] The only sense in which the class hierarchy is relevant at the application level is that a subclass will have all of the attributes of its parent class.
I don't think you should dismiss the importance of this. If Haskell allowed just one member function per class and didn't provide class inheritance, class contexts would be many, many times larger than they are now. Just look at all the things that you can do with an instance of 'Num'.
In any case, it probably isn't practical to model the class hierarchy in the CGA, as different toolkits have different hierarchies (e.g. Motif's push-button class is a subclass of label, but Qt's isn't).
Remember that we're not interested in the internal details of widgets or even in the interfaces between widgets - as you say, this is only relevant if we're writing new widgets (which we're not). What we're interested in is the external interfaces of widgets. Our concern for portability of applications will force us to standardize these external interfaces across all implementations of the CGA. Once the set of operations and attributes is standardized, there is no problem using Haskell-style inheritance to make types more concise. Or, to put it another way: OO-style inheritance is about inheritance of implementation whereas Haskell-style inheritance is about inheritance of interface. Since the underlying library (Athena, Motif, Tk, etc) provides the implementation, we're free to focus on the interface and, fortunately, Haskell-style inheritance is well suited to this task. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/