Re: [Haskell-cafe] Re: OO Design in Haskell Example (Draft)
The composite design pattern implemented using record types,
where the named elements are the interface to the object
Overall, I think I agree with Tim that the record types are simpler to code.
I'm not sure, though, what would happen if I tried to add state to the
types. With the previous example, using existentials to create a reference
type that holds elements of a type class that matches the interface, I think
that it would be natural to hold state by having that element stored in a
mutable state variable, and replacing the held values.
In any case:
Two methods, add and draw
data Component = Component {
draw :: String,
add :: Component - Component
}
A constructor for the leaf type, which holds a string
leaf :: String - Component
leaf s =
Component draw1 add1
where draw1 = show s
add1 _ = leaf s
the draw method for the composite type
(because I was having trouble with layout and formating for 72 cols)
compositeDraw :: [Component] - String
compositeDraw [] = ()
compositeDraw leaves = ( ++ (foldr1 (++) $ map draw leaves) ++ )
A constructor for the composite type, which holds a list of components
and dispatches to the contained elements
composite :: [Component] - Component
composite cs =
Component draw1 add1
where draw1 = compositeDraw cs
add1 c = composite $ c:cs
On 2/27/07, Tim Docker [EMAIL PROTECTED] wrote:
Steve Downey wrote:
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.
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.
I suspect there's no right answer - it's a case of choosing the
best approach for the problem. As an example, my charting library
(http://dockerz.net/software/chart.html) uses the record of functions
approach for composing drawings:
data Renderable = Renderable {
minsize :: (Render RectSize)
render :: (Rect - Render ())
}
Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OO Design in Haskell Example (Draft)
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, [EMAIL PROTECTED] [EMAIL PROTECTED] 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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OO Design in Haskell Example (Draft)
I just started reading Haskell's overlooked object system. http://www.cwi.nl/%7Eralf/OOHaskell/ The survey of existing object encodings looks like a good place to start, although for several, where Either is used as a union type there are some rather obvious scaling problems. g If I've understood it, the OOHaskell library is meant to be a way of exploring OO in Haskell. Is it something that should be used by someone who wants to implement an OO design today? Or is it more for someone interested in research into the best way of doing OO in a functional context? I agree that there are a number of thorny OO issues, particularly that there really isn't a single OO model, rather a number of related models, practices and principles that are all lumped into the context of OO. Not to mention the tension between a model that revolves around mutable state against a system built on referential transparency. Mostly, I'd like to see better answers to questions like 'how do I do this' than here's something that will let you build something that lets you do that. I tend towards the engineering / reduction to practice side of things. Much as I like theory. And even if the answer is, there isn't really a best answer, but here are two or three reasonably good ways that won't cause too much trouble, and here's the kind of trouble they are likely to cause. On 2/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Steve Downey wrote: In the last OO design in Haskell thread (and probably in every one preceeding it), it was suggested that having some examples might be a good idea. Since most people with existing designs will have some familiarity with Design Patterns, and those are typical building blocks for OO designs, it occured to me that implementing some of them might be a useful excersize. Have you looked at OOHaskell? http://homepages.cwi.nl/~ralf/OOHaskell/ http://darcs.haskell.org/OOHaskell/ With the exception of pure-functional objects and binary methods, I think we have considered almost every OO pattern/idiom we could find, including nominal/structural subtyping, co- and contra-variance, self-typing, etc. The DARCS repository contains the complete code for all of the examples and patterns. To clarify, the point of OOHaskell is to use Haskell as a tool, laboratory bench, for exploring various (thorny) OO issues. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OO Design in Haskell Example (Draft)
Steve Downey wrote:
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.
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.
I suspect there's no right answer - it's a case of choosing the
best approach for the problem. As an example, my charting library
(http://dockerz.net/software/chart.html) uses the record of functions
approach for composing drawings:
data Renderable = Renderable {
minsize :: (Render RectSize)
render :: (Rect - Render ())
}
Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
