[GUI] State, Attributes and Some basic widgets

[Alastair Reid]

Glynn Clements <glynn.clements@virgin.net> writes:
> 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/