

Functions are data (and very cool data, too) - dons
http://jaspervdj.be/posts/2009-12-23-functions-are-data.html

======
silentOpen
What's the problem that is actually trying to be solved? The user of your
implementation will inform the design choices you make.

Using functions to represent objects like this is rather silly because they
are opaque and only support a single operation.

Here are a number of possibly better ways to do it:

    
    
      - Emulate objects with functions and messages like with scheme or lisp.
    
      - Use structural typing or polymorphic variants like in OCaml.
    
      - Use records with function fields.
    
      - Use a variant union.
    
      - Extend/build a list monad over your class.
    

Can you think of other or better ways?

------
Retric
The OO approach would be to have a virtual function in the parent class and
then use lists of the parent class type. Does Haskell prevent that from
working, or is he just attacking the OO approach based on a bad OO design?

~~~
twp
I'd argue that he's using a bad FP approach. He focuses on one aspect of
shapes: testing whether a point is inside it or not. But this is far from a
complete, usable representation. How do you draw a shape? Find its edge? Find
its bounds? Convex hull? Transform? Test for convexity?

Basically, the original post is just another newbie FP realising that - hey -
if you're only every going to call one function of a class then the class is
completely defined by that function. He presents a poor and incomplete
solution.

There are much better blog posts on FP design than this. Please don't upvote
this one.

------
joe_the_user
Doe sql injection count?

