These are chat archives for nrinaudo/kantan.csv

16th
Feb 2017
Nicolas Rinaudo
@nrinaudo
Feb 16 2017 18:16
@/all I'm thinking of introducing a compatibility-breaking change for next release and would like to know how much I'd be alienating you guys
the general idea is to have some sort of CsvConfig type which would hold all CSV configuration options (column separator, quote character...), and use that when reading / writing CSV, rather than explicitly passing them to, say, asCsv
this, of course, would mean that every single call to asCsv and similar methods will break when upgrading
Andrew Roberts
@aroberts
Feb 16 2017 19:47
would config be implicit or explicit?
Nicolas Rinaudo
@nrinaudo
Feb 16 2017 21:14
My current plan is for it to be implicit, or to go through the ReaderEngine and WriterEngine mechanism somehow
(like the way the external readers and writers work since today's commits)
Andrew Roberts
@aroberts
Feb 16 2017 22:06
One thing worth keeping in mind is that many applications for data formats are heterogenous in nature - e.g. reading one format, transforming, writing another. Implicit configuration at this level makes this a bit tricky, since the two different configurations would conflict in the scope of the client.
(I think it’s possible to call methods w/ implicit params with explicitly materialized objects, so that could be one avenue, but it still seems a bit awkward)
Carlos Quiroz
@cquiroz
Feb 16 2017 22:10
I have no troubles with that change, I'll adapt my code
Nicolas Rinaudo
@nrinaudo
Feb 16 2017 22:26
@aroberts that's correct, but also something that kantan.csv already suffers from - if only because of scala.io.Codec. Whenever you want to read in UTF-8 but write in ISO-LATIN-1, for example...
and in your example, if I were to go the way of ReaderEngine / WriterEngine way, there would be no problem:
implicit val readerEngine = InternalReaderEngine.from(configA)
implicit val writerEngine = InternalWriterEngine.from(configB)
this lets you read data in configA, but write it with configB
but yes, this does still require some thoughts
@cquiroz thanks. Not sure if I'll even end up making the change - I'm just toying with the idea for now - but thanks for being flexible