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 achieve this? Levi