> > > Ok, so far that's an argument for polymorphism in the language. Now why > inheritance? When talking about things, it really makes your life > easier to give them names. I want to be able to specify an algorithm in > terms of fruits, and later be able to refine it by saying "hey, a banana > is a fruit, and by the way, you need to peel it before cutting it to > pieces". That's a named abstract concept here, and an IS-A > relationship, and polymorphism. OO, if you want. I'd feel very > uncomfortable having to talk about "objects with fruit-like properties > in taste and texture and support for a polymorphic cut method" all of > the time, it's much better to be able to talk "fruits". This closely > corresponds with my frustration when using C++ templates or > Haskell/ML-style languages with algebraic data types: compile time type > errors spanning multiple screen pages make my poor brain hurt. "Cheese > is not a fruit" is much easier to parse. > It's interesting that the example you used seems to better describe Haskell typeclass style of OO rather than the traditional OO. That is to say that a banana is a type of fruit. There are several operations upon which you can perform to a fruit, and thus, a banana.
The difference is subtle, but it's a more natural style of classification, it's the kind that is used in science. e.g. A Zebra is a type of animal, and a type of mammal and a type of quadriped. Therefore, the characteristics you would expect from any of those classifications are guaranteed to be present in a zebra. Notice that inheritance wasn't mentioned anywhere in this description. Zebras don't inherit their traits from their classifications, because they aren't their parents, but the classifications still provide guarantees. This is actually what I love about Haskell's typeclass system. You get classification and you get guarantees as to interfaces, but you don't have to muck around with inheritance to get it. There are some things that I think could be made more streamlined in haskell (e.g. datatype access) . The Objects/GADTs paper seem to summarize those nicely. So so summarize, I vote yes for typeclasses, no for inheritance. Just my two cents. Rick Richardson
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
