Consider dropping Data.Has
akhra opened this issue · comments
I keep running into issues arising from Has
, and especially its interplay with the concrete HasFoo
class idiom. Today this culminated in encountering a runtime loop on code that shouldn't even typecheck (trivial reproduction here). This has thoroughly convinced me that @snoyberg chose the more stable path with RIO
, and I've now fallen back to exclusively using HasFoo
(with the exception of one instance Has ModHttpClient AppEnv
since that's required to use the API).
HTTPClient
does not import Data.Has
and uses HasHttpManager
in MonadHTTP
, so you can use Network.HTTP.Client.TLS.newTlsManager
directly instead of newHttpClient
.
I've extracted Has
stuff into a separate module.
If all these HasFoo
classes already had instances for tuples, I guess we wouldn't actually need Has
…
If all these HasFoo classes already had instances for tuples
Good point. And generating those is arguably within the scope of commercialhaskell/rio#113. I'll try to take another whack at that soon.
generic-lens
is like has
++ ;)
type MyEnv = (Fooby, Barby, Bizzy)
whop :: RIO MyEnv Response
whop = do
fooby <- view (the @Fooby)
...