Open tomjaguarpaw opened 10 years ago
Another solution is to merge these functions to only type class constrained ones. If someone still wants to do something custom they can add a newtype. Is usage common enough that this will become annoying? Since no functionality is lost I'd rather see this than having an API of twice the size where most things are unused.
Otherwise I'd recommend sticking the others in an Internal
module which at least signals "this is probably not what beginners are looking for" to make the haddocks easier to navigate.
However this is solved it's a good change!
I've come across far too many libraries that didn't allow explicit dictionaries to be passed without due reason. This is a big impediment to reusability. postgresql-simple had to end up adding queryWith
for this reason. So the the non-typeclass versions will definitely stay, but I'm happy to hide them away somewhere less prominent. (In fact reducing their prominence is the main reason for the name change.)
I would support an identical names but in a different module solution. It makes uniform namespacing easy (just import qualified), and make it a very easy to figure out the analogous functions. This seems better than adding an arbitrary suffix that may or may not mean much.
My best idea so far is runQueryExplicit
, toQueryArrExplicit
. Feel free to chime in ...
We have a lot of functions with
Default
constraints named like...Def
or...Default
(e.g.runQueryDefault
ortoQueryArrDef
.The user will probably use the
Def
versions much more frequently than the non-Def
version so it would make sense to remove the suffix and add a suffix for the non-typeclass versions. This is what happened with the newORDER BY
functionality.orderBy
is theDefault
version andorderByU
is the non-typeclass version.I would like to make this breaking change throughout the whole codebase. Any comments? Any suggestions for replacement suffix?