On Sun, May 27, 2012 at 7:07 PM, Richard O'Keefe <[email protected]> wrote:
>
> On 26/05/2012, at 4:16 AM, David Turner wrote:
> >
> > I don't. I think the trouble is that classes don't add value in
> exercises of this size.
>
> This was the key point, I think.
> In this example, there wasn't any significant behaviour that could be moved
> to superclasses. For that matter, whether a supplier is plain, preferred,
> or problematic is, one hopes, not a *permanent* property of a supplier.
>
> Sometimes higher-order functions can substitute for classes.
Functors can always substitute for OO classes. A class system is a functor
from the set of objects to a set of methods, mediated by inheritance, or
things like message-passing, duck typing, prototyping, etc.
Functions with the type Foo -> Foo can be easily used to implement a
prototype based dispatch mechanism. Indeed, this is a common Haskell
pattern. Define:
-- Library code:
defaultFoo :: Foo
defaultFoo = Foo { bar = ..., baz = ... }
-- Client code
myFoo = defaultFoo { bar = myBar }
Things can get as complicated as you would like, up to and including
inheritance, by using functors other than ((->) a)
The defining characteristic of OO is that objects are stateful, but
self-contained entities. How methods are defined and dispatched vary
wildly across OO languages.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
