
On Tue, Apr 29, 2003 at 09:43:18AM +0100, Alastair Reid wrote:
Wolfgang Thaller
writes: The example implementation already had a "Widget" type; a Widget type would be necessary when you want to have heterogenous lists of widgets. That's why somebody brought up the idea of having the toWidget and fromWidget functions; Nobody protested when the idea was first proposed, so I assumed that it was agreed.
By itself, there's no problem having a Widget type and to/fromWidget operations. After all, with _only_ those two operations, there's not that much you can do with them.
But, the moment we add additional operations which act on objects of type Widget and not on objects in the Widget class, my gut tells me there will be problems. I was keeping quiet until such operations were proposed since it'd be easier to point out problems with concrete examples in front of us.
IMHO the classes should just reflect the object hierarchy. If we have e.g. class Button b where... class ToggleButton b where... instance Button ToggleButton where... then we can have the simple function onActivate :: Button b => b -> IO () -> IO () and use it with ToggleButton as well (but not with a plain Widget or anything on the other branches of the tree). Having onActivate as a class member doesn't give any improvement in type safety, is less efficient (bigger dictionaries) and doesn't lend itself to automatic creation of this type hierarchy. Axel.