As a side note, I think that in the vast majority of cases where you think that a type class is be a good solution - it's not. :-}
This has been said a lot, which is why I was looking for suggestions. I
didn't think about separating them into different modules. It might work.
I think, for now, I'm going to keep it simple and just use the "fast" case
and worry about how to refactor to use both, when it comes to it.
Peter
On 2 July 2013 08:13, Frerich Raabe
Hi Peter,
Am 7/2/2013 12:52 AM, schrieb Peter Hall:
The other problem I'm facing is with name collisions for record
accessors. There are two versions of MtGoxTicker from different services - one with a subset of the properties, which is supposed to be faster (it isn't, but that isn't the point). The data types are here https://github.com/peterjoel/**auto-trader/blob/** 6974d66ae51459479c19be291d075b**bdeb718b53/AutoTrader/MtGox/**Types.hshttps://github.com/peterjoel/auto-trader/blob/6974d66ae51459479c19be291d075b... . One is commented one out while I decide what to do. What is the best way to model those records to avoid collisions, while not being confusing to users of the library? I am very tempted to use type classes, but that feels naughty. Using unique prefixes seems bad too - it would be nice for some code to be able to use them interchangeably if they don't need all the fields.
This sounds like a good case for two separate modules:
AutoTrader.MtGox.Ticker.Full would have a data Ticker = Ticker { .. } which is the commented-out MtGoxTickerFull, and AutoTrader.MtGox.Ticker.Fast would balso have a 'data Ticker = ...', which would be your MtGoxTicker.
This would allow you to use the same field names without getting clashes, users of your library could choose hwo to import the types, i.e. what prefix to use - and people using no fields from the full ticker could switch their code by changing something like
import qualified AutoTrader.MtGox.Ticker.Full
to
import qualified AutoTrader.MtGox.Ticker.Fast
As a side note, I think that in the vast majority of cases where you think that a type class is be a good solution - it's not. :-}
-- Frerich Raabe - raabe@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
______________________________**_________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/**mailman/listinfo/beginnershttp://www.haskell.org/mailman/listinfo/beginners