[Haskell-cafe] FP design
levi.stephen at optusnet.com.au
Wed Nov 7 18:06:28 EST 2007
Donn Cave wrote:
> But in the specific matter I'm wrestling with, the Java library's OOP
> model is, to its credit, allowing me to do some things. I'm using their
> standard LDAP client library, but swapping in my own function to read
> X509 certificates for the SSL. Actually, swapping in my own SSL socket
> "implementation", which in my case just calls the standard library SSL
> socket implementation to do most of the work.
> Now it's not like I can't imagine it working better - it may be a little
> fragile, for one thing - but I have wondered what facilities a Haskell
> design could have drawn on to de-couple implementation components like that.
> Let's say you download an IMAP mail client library, and look to see if it
> can operate on a UNIX pipe; on an SSL socket; authenticate with GSSAPI
> Kerberos 5 -- when none of those things are supported out of the box.
> (As I have needed, and done, all three of those with the standard Python
> IMAP library module.) You may also want its I/O operations to integrate
> with some dispatching core, for a GUI. But of course you also want the
> basic interface to be simple in this area - the IMAP protocol itself is
> complicated enough!
I have similar questions about Haskell abstracting away implementations behind
interfaces as well. I have become used to an approach where I will not worry
about databases/persistence when beginning. I will create an interface to a
database layer (e.g., save(object), retrieve(id), findByName(name)) etc., and an
implementation that uses in memory collections to begin with. Later I will
replace this with database calls.
This also helps in my current project as we support multiple databases. If
findByName requires different SQL on different databases it's easy to have a
different implementation used at run time.
How does this type of approach work in Haskell? or what is the Haskell way to
More information about the Haskell-Cafe