I just started reading <a href="http://www.cwi.nl/%7Eralf/OOHaskell/" class="l" onmousedown="return rwt(this,'','','res','1','__CzlET5UXikchEGv6jwReAhPCmzQ=','&sig2=38KmVI0i449NSVsfTYFKnA')">
"Haskell's overlooked object system". </a><br>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>
<br><br>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?
<br><br>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.
<br><br> 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.
<br><br><br><div><span class="gmail_quote">On 2/26/07, <b class="gmail_sendername"><a href="mailto:email@example.com">firstname.lastname@example.org</a></b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Steve Downey wrote:<br>> In the last OO design in Haskell thread (and probably in every one<br>> preceeding it), it was suggested that having some examples might be a good<br>> idea.<br>><br>> Since most people with existing designs will have some familiarity with
<br>> Design Patterns, and those are typical building blocks for OO designs, it<br>> occured to me that implementing some of them might be a useful<br>> excersize.<br><br>Have you looked at OOHaskell?<br>
<a href="http://homepages.cwi.nl/~ralf/OOHaskell/">http://homepages.cwi.nl/~ralf/OOHaskell/</a><br> <a href="http://darcs.haskell.org/OOHaskell/">http://darcs.haskell.org/OOHaskell/</a><br><br>With the exception of pure-functional objects and binary methods, I
<br>think we have considered almost every OO pattern/idiom we could find,<br>including nominal/structural subtyping, co- and contra-variance,<br>self-typing, etc. The DARCS repository contains the complete code for<br>all of the examples and patterns. To clarify, the point of OOHaskell
<br>is to use Haskell as a tool, laboratory bench, for exploring various<br>(thorny) OO issues.<br></blockquote></div><br>