<div dir="ltr">> 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. :-}<br><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Peter<br><br><br><div class="gmail_quote">On 2 July 2013 08:13, Frerich Raabe <span dir="ltr"><<a href="mailto:raabe@froglogic.com" target="_blank">raabe@froglogic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Peter,<br>
<br>
Am 7/2/2013 12:52 AM, schrieb Peter Hall:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The other problem I'm facing is with name collisions for record<br>
accessors. There are two versions of MtGoxTicker from different services<br>
- one with a subset of the properties, which is supposed to be faster<br>
(it isn't, but that isn't the point). The data types are here<br>
<a href="https://github.com/peterjoel/auto-trader/blob/6974d66ae51459479c19be291d075bbdeb718b53/AutoTrader/MtGox/Types.hs" target="_blank">https://github.com/peterjoel/<u></u>auto-trader/blob/<u></u>6974d66ae51459479c19be291d075b<u></u>bdeb718b53/AutoTrader/MtGox/<u></u>Types.hs</a>.<br>
One is commented one out while I decide what to do. What is the best way<br>
to model those records to avoid collisions, while not being confusing to<br>
users of the library? I am very tempted to use type classes, but that<br>
feels naughty. Using unique prefixes seems bad too - it would be nice<br>
for some code to be able to use them interchangeably if they don't need<br>
all the fields.<br>
</blockquote>
<br></div>
This sounds like a good case for two separate modules:<br>
<br>
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.<br>
<br>
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<br>
<br>
import qualified AutoTrader.MtGox.Ticker.Full<br>
<br>
to<br>
<br>
import qualified AutoTrader.MtGox.Ticker.Fast<br>
<br>
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. :-}<span class=""><font color="#888888"><br>
<br>
-- <br>
Frerich Raabe - <a href="mailto:raabe@froglogic.com" target="_blank">raabe@froglogic.com</a><br>
<a href="http://www.froglogic.com" target="_blank">www.froglogic.com</a> - Multi-Platform GUI Testing<br>
<br>
<br>
______________________________<u></u>_________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/beginners</a><br>
</font></span></blockquote></div><br></div></div>