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
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