Re: [htoolkit-users] Design question of Connection from HSQL

[Krasimir A. <ka2...@ya...>]

--- Marc Weber <mar...@gm...> wrote:
> class Connection c where
>   connDisconnect :: c -> ()
>   connPrepare :: c -> String -> IO Integer
>   [...]


It isn't that simple. You will need something like
this:

class Statement s where
  stmtExecute :: s -> IO ()
  stmtFetch   :: s -> IO Bool
  [..]

class Statement s => Connection c s | c -> s where
  connDisconnect :: c -> IO ()
  connQuery      :: c -> IO s
  [..]

I always prefer to keep the types as simple as
possible. The current solution is Haskell 98 and the
types are much simpler. With the simpler types the
compiler will generate simpler type checking errors. 

The goal was to allow to connect at one place and
after that to use the @Connection@ and @Statement@
values in all places without need to know the actual
database backend. With your proposal you will have to
use type classes everywhere. 

The proposal has the advantage that with it you can
provide more backend specific functions. This can be
achieved in another way too. The handles can be
defined as:

data Connection a 
  = Connection 
       { connHandle  :: a
       , connExecute :: a -> String -> IO ()
       , connQuery   :: a -> String -> IO (Statement
a)
       [..]
       }

data Statement  a = ....

then in Database.HSQL.MySQL:

connect :: String -> String -> IO (Connection MySQL)

With this design all platform independent functions
will use @Connection a@ while the MySQL specific will
be restricted to @Connection MySQL@. This design isn't
implemented yet because HSQL doesn't have any platform
specific functions and I don't want to change the API
without serious reasons.

Cheers,
  Krasimir

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com