[Haskell] Dynamic binding

Ralf Lammel ralfla at microsoft.com
Wed Jun 22 23:54:13 EDT 2005


At the risk of being excluded from this list
(because of an unmoral number of plugs about OOHaskell),
here we go: http://homepages.cwi.nl/~ralf/OOHaskell/

You might start with the appendices of the paper and also read Section 2
which finally implements the Shapes example with ease. The C++ encoding 
is a bit verbose in so far that C++ doesn't quite have type inference,
Haskell does and so OOHaskell does too :-)

Apologies,
Ralf


> -----Original Message-----
> From: haskell-bounces at haskell.org [mailto:haskell-bounces at haskell.org]
On
> Behalf Of Andrew Ward
> Sent: Wednesday, June 22, 2005 6:38 PM
> To: Pal-Kristian Engstad
> Cc: haskell at haskell.org
> Subject: Re: [Haskell] Dynamic binding
> 
> Pal-Kristian Engstad wrote:
> 
> >On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:
> >
> >
> >>What would be the normal way for a Haskell programmer to handle the
> >>typical shape example in beginner OO tutorials?
> >>
> >>
> >
> >By not doing OO. You have to ask yourself, what is the purpose and/or
> benefit
> >of using OO? In C++, OO is _useful_ because you restrict the problems
of
> >mutable data (by enclosing it in C++ classes).
> >
> >ML type languages have other methods of doing things, and guess what,
OO
> is
> >not that needed for these languages. Sum-types, pattern-matching and
data
> >constructors make half of the need for OO go away. Higher order
functions
> and
> >make it even less needed. For the rest, there's always work-arounds.
> >
> >PKE.
> >
> >
> To handle the problem of drawing all shapes, in c++, I would have a
list
> of shape pointers:
> 
> struct shape{ virtual void draw(...);};
> struct circle : public shape {...};
> struct square : public shape {...};
> std::list<shape *> shapes;
> for(std::list<shape *>::iterator it = shapes.begin();it !=
> shapes.end();++it)
> { (*it)->draw(...); }
> 
> This general pattern of dynamic binding I use over and over again.
Could
> you give me some example code of this type of thing handled in
Haskell's
> way? Assuming that the number of classes deriving from shape might get
> quite large.
> 
> Andrew Ward.
> 
> 
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell


More information about the Haskell mailing list