These are chat archives for nrinaudo/kantan.csv

12th
Sep 2018
Andrew Roberts
@aroberts
Sep 12 2018 19:20
hm, am I missing something here?
    implicit val csvEncodeDepartment: RowEncoder[Department] = RowEncoder.ordered(_.departmentName)
that doesn’t compile
oof
needs to be
    implicit val csvEncodeDepartment: RowEncoder[Department] = RowEncoder.ordered((d: Department) => d.departmentName)
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 19:27
with a single parameter, you should be able to write:
implicit val csvEncodeDepartment: RowEncoder[Department] = RowEncoder.encoder(_.departmentName)
with multiple parameters: yeah :(
if I remember correctly, that's a tradeoff I took rather than have ordered2, ordered3, ordered4...
although I'll be honest: I don't know why the type inferrer can't work it out
@aroberts :arrow_up:
Andrew Roberts
@aroberts
Sep 12 2018 19:30
thanks
yeah, it’s too bad
Andrew Roberts
@aroberts
Sep 12 2018 20:23
is there anything to help encoding ADTs?
e.g. if I have RowEncoder[Child1] and RowEncoder[Child2] (and there are no other children), is there a way to either infer or concisely define RowEncoder[Parent]?
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:24
depends on the shape of your ADT
if it's either just a sum type or just a product type, then yes. Otherwise, no, not really, because how do you map that to CSV?
but for your example, do you mean something like:
sealed abstract class Bool extends Product with Serializable

object Bool {
  case object True extends Bool
  case object False extends Bool
}
?
if so, this is supported by the shapeless module
Andrew Roberts
@aroberts
Sep 12 2018 20:26
thx
I think it’s a sum type of different product types?
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:27
Bool is just a sum type, but if your exampe is a sum type of different product types, it should work
Andrew Roberts
@aroberts
Sep 12 2018 20:27
do I need to add the generic dependency for that?
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:27
the output will just be very weird - rows will not always have the same number of cells, or the same meaning for the same cell
yeah, you do
Andrew Roberts
@aroberts
Sep 12 2018 20:28
yeah, I’m good with that
the particular child will be the same for all rows in a data set
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:28
wouldn't you rather write an encoder for each child, and get your dataset properly typed?
Andrew Roberts
@aroberts
Sep 12 2018 20:29
I have an encoder for each child
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:29
instead of having a Dataset[Parent], get a Dataset[Child1], to express the fact that your dataset only contains Child1?
Andrew Roberts
@aroberts
Sep 12 2018 20:29
but it’s only in the export context that the child type is fixed that way
that type change ripples quite far through the API, into places where I don’t want that requirement to exist
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:30
I don't understand the constraints you work with, so this might be reasonable. It's just, to me - if you can't express it in the types, it means that, sooner or later, the constraint will be violated
Andrew Roberts
@aroberts
Sep 12 2018 20:30
yeah, I definitely hear that argument
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:31
but if you can't, you can't, and you need the generic dependency to allow kantan.csv to work out that given a sum type of types it has an encoder for, it has an encoder for the sum type
or you can write it manually if you don't want a shapeless dependency - if you don't have too many alternatives, it should be manageable. I think there's even a helper for it
RowEncoder.oneOf, something like that?
ah, no, that's for decoders. Mmm. Maybe there's something I can do there
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:36
or not - the types would be a bit nasty, with subtyping and all
Andrew Roberts
@aroberts
Sep 12 2018 20:42
yeah
I’m re-exploring pushing the parent/child type up into a type parameter of my dataset, as opposed to having it all upcast to parent
for the nth time haha
Nicolas Rinaudo
@nrinaudo
Sep 12 2018 20:57
Good luck :)