2009/8/7 Will Donnelly <will.donne...@gmail.com>: > >> class Serialize a where >> read :: FilePath -> IO a >> write :: a -> FilePath -> IO () > > I understand that approach. My feeling on the matter is that it is a > bad idea if taken to its logical conclusion. Eventually every library > that could possibly need to serialize data would end up with its own > typeclass for serialization.
Why? It could exist in a separate package. > It is much better, in my opinion, to say > "use text, or use binary". And it bears pointing out that Data.Binary > requires an instance declaration for the 'Binary' typeclass, and (I > believe) there isn't really anything preventing you from outputting > whatever arbitrary data you desire using it. What if another, better, Binary class comes along? Regarding outputting arbitrary data, I'm not sure about this but I think Binary should only be used for binary formats. You are right that it could act as the proxy class, though. > I am generally in favor of allowing more customization to the user of > a library, but can you name some specific situations in which neither > Read/Show nor Data.Binary would suffice? Other formats: XML, Protocol Buffers Other storage: network (replace FilePath with some general Handle type) "code against an interface, not an implementation". So, I understand that this might be too complicated at this stage, but I just thought I had to defend this point a little. David --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
