Well, I'm thinking in terms of OOD/OOA/OOP -- Design, Architecture, Programming. That's about the only way to model a bog system. Say I have a stock market model -- I'll have a database of tickers, a simulator to backtest things, a trading strategy, etc.
Do Haskell modules provide enough encapsulation to design a system in terms of them? What are the design/architecture units in Haskell if not OO-based? Cheers, Alexy On 1/27/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote:
deliverable: > ...In the tradition of the "letters of an ignorant newbie"... > > What's the consensus on the OOP in Haskell *now*? There're some > libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified > type system with inheritance. > > If I have GHC, which way to do anything OOP-like is considered "right" > today? Using existentials and typeclasses to do some OO things wouldn't be considered unidiomatic (particularly, using existentials to package up interfaces to values). In general though, using a functional approach will produce better (simpler) Haskell code, and make it more likely others will understand it. Personally, I run in fear from OO Haskell ;) Concrete examples of when you think you need an OO feature might be useful, so people can discuss the more FP solutions to the same problem. Cheers, Don
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
