[Haskell-cafe] Re: OO Design in Haskell Example (Draft)

[Steve Downey]

interesting. it leads to something that feels much more like an object
based, as opposed to a class based, system.
as far as haskell is concerned, everything has the same type, even
though different instances have very different behavior.
instance variables are captured by the closures that define the object
methods,  through the instance construction functions.
i get the feeling that a model like 'self''s , based on prototypes,
would not be that hard to implement.


i should have the equivalent example with this style done soon.

the question is, which plays nicer with the rest of haskell? that is,
if i'm not committing to a closed dsl, which style is more likely to
be reusable against other libraries.

my experience so far has been with parsers and type checkers that make
extensive use of pattern matching, which is why I probably gravitated
towards the type class with existentials solution. but my experience
is limited.

On 2/26/07, apfelmus at quantentunnel.de <apfelmus at quantentunnel.de> wrote:
> Tim Docker wrote:
> > Steve Downey wrote:
> >  > So, I've been working on a Composite example. I've used
> >  > existential types to have a generic proxy to the base
> >  > type, rather than a simple algebraic type, since adding
> >  > new leaves to the algebraic type means modifying the whole
> >  > type, a violation of the Open-Closed principle (open for
> >  > extension, closed for modification)
> >
> > Rather than using existential types, a simple record of
> > functions can be often be useful. ie:
> >
> > data Component = Component {
> >     draw :: String
> >     add  :: Component -> Component
> > }
> >
> > It might be worth comparing this approach with the (more
> > complex) one you have described.
>
> The point about existential types is that every class like IComponent
> that allow as useful existential like
>
>   data Component =
>     forall e.(IComponent e) => Component e
>
> can be put into the record form Tim mentions. See the old wiki pages at
>
>    http://haskell.org/hawiki/ExistentialTypes
>
> This is because every such IComponent has to look like
>
>   class IComponent e where
>     foo1 :: e -> ... -> e
>     ...
>     bar1 :: e -> ...
>     ...
>
> where the dots in "-> ..." must not contain the type variable e.
>
>
> Regards,
> apfelmus
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>