On Jun 22, 2005, at 9:38 PM, Andrew Ward wrote:
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.
It seems to me that if this is the specific problem being addressed, a
list of higher-order functions is exactly the right solution in any
ML-like language, and this is why there have been several responses to
that effect.
I do think it's fair to say "consider changing the way you think" to OO
programmers trying to learn Haskell. If we were on an OOP mailing
list, I could ask for days how to simulate pattern matching and
algebraic types---and get a nonsensical runaround involving the visitor
pattern and huge swaths of unreadable code.
Ralf, I think it's incumbent on you, having said several times "that
isn't solving the problem", to more clearly explain what problem you
think exists and cannot be solved gracefully (I suspect it has to do
with extensible down-casting---which is indeed hard in Haskell, but
many reasonable people might consider irrelevant or even overtly bad).
Andrew, if this isn't the problem you're actually trying to solve, can
you explain why a simple list of functions doesn't help you?
-Jan-Willem Maessen
Andrew Ward.
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
