If you always expect to be passing c as a parameter and never
returned, it is probably better off as a data type. Eg. HTTPClient
might look like a traditional OO class:
class HTTPClient c where
foo :: c -> stuff
bar :: c -> stuff
I've found that it is easier to work with if you use a data type instead:
data HTTPClient = HTTPClient {
foo :: stuff,
bar :: stuff
}
But other than that, yeah that's about right. If you want a function
to be polymorphic in something, take the something as a parameter.
Simple as that.
Luke
On Fri, Jan 7, 2011 at 8:01 PM, Daryoush Mehrtash
I am trying to evaluate the polymorphism technique used in Hackage library. I like to know if the approach taken is "right" or not.
The code in question is in the Hoaut package http://hackage.haskell.org/package/hoauth/
As far as I can understand the code wants to have polymorphism on HTTP client such that it can use different underlying HTTP. The package comes with Curl and Debug implementation of its HTTPClient class.
My question is with how the polymorphism is used. In function such as "serviceRequest" in the Network.OAuth.Consumer module you have:
-- | Performs a signed request with the available token. serviceRequest :: (HttpClient c,MonadIO m) => c -> OAuthRequest -> OAuthMonadT m Response
serviceRequest c req = do { result <- lift $ runClient c (unpackRq req)
; case (result)
of Right rsp -> return rsp
Left err -> fail $ "Failure performing the request. [reason=" ++ err ++"]"
}
The function expects the HTTPClient implementation to be the first argument to the function. Is that the right thing to do? Or should the instance of the client be a type parameter in the computation (in this case OAuthMonadT)?
thanks,
Daryoush
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe