shapeless: Generic programming for Scala | This room deprecated in favour of #shapeless on the Typelevel Discord: https://discord.gg/bSQBZA3Ced
however,
describer probably needs some modification, it doesn't compile if your case classes have Lists in them
but the basic idea is there
mm, no, there'a problem
but it's a problem with the whole idea, not with the implementation
what do you want the behaviour to be if your classes contain things like
List Option, and in general, data types with alternatives?
@SystemFw in that fiddle i try to do just that but it doesn't work
the basic problem is this: how do you distinguish between a
Baz and a List?
also note that my solution was merely for the example at the beginning, if you want different strategies for unpacking different things you are probably better off moving away from the
Poly towards a custom type class (even though you get to keep, with small adaptations, most of the code in the instances)
the reason for that is my approach first flattens, then describes
if you want
Lists to be printed differently, e.g. 1..2, add an instance to describer
@SystemFw please see my fiddle here: https://scalafiddle.io/sf/8e8Kbup/1
it is not picking up and using
it is not picking up and using
forTraversable()
@SystemFw so I do want
Lists to be printed differently which is why I added an implicit def to construct a type class for List[Int]. it should display lists as [1,2]
because
Describe is not being resolved recursively
(you could do it that way, but you need to change my code first)
I can tweak it to accommodate your use case I think
so, iterables should be
[1,2,3] and so on right? or [1] if they have one element
anyway what you want can be done with my approach
but it would probably be cleaner if you just used a custom, recursive typeclass instead of
Polys
@davidhoyt I don't have any more time to write code I'm afraid, but I can tell you how to do it :)
first, add add
<: HList to the R type parameter in kv
second, you need to modify
base in LowPrioDescriber to take an implicit f: Format[V]where Format is a typeclass that converts types to String
then you replace
.toString with f(x: V)
if
Format sounds similar to Describe, it's because it is! Hence my point about all this being probably better if rewritten from scratch as a recursive typeclass
However, you can reuse my code to implement what you wanted in your original question, i.e. how to flatten arbitrarily nested case classes, while preserving their
LabelledGeneric#Repr type to get access to the field names later
@SystemFw did it -- appears to be working thanks :) looks like it doesn't work on
HLists themselves though. here's the latest: https://scalafiddle.io/sf/8e8Kbup/4
i guess it doesn't work on
HList since it can't create LabelledGeneric for the example I tried. makes sense. :)
@SystemFw this is all I need it to do -- anything else to be gained by rewriting?
looks like it won't work with coproducts :/
I am trying to modify a CSV parser library
implicit def caseClassParser[Case, Repr <: HList]
(implicit
gen: LabelledGeneric.Aux[Case, Repr],
reprParser: Lazy[CsvParser[Repr]]): CsvParser[Case] = {
instance(reprParser.value.size) { cells =>
reprParser.value.parse(cells).right.map { parsed =>
(gen.from(parsed))
}
} { c => reprParser.value.to(gen.to(c)).init }
}
if gen is Generic, it works, but LabelledGeneric does not
Case is supposed to work for case classes
the individual elements of a
Repr have a different type in Generic and LabelledGeneric, since in the latter the type also carries evidence of the field names