RelGraphDecoder for a case class that has a String or Long as one of its fields (either directly, or by means of another case class). And Magnolia can't construct the CaseClass instance with Param instances for each field unless it can find those implicit instances you've just defined.
null is one way to represent that. (There may be better ways...)
combine method would use the typeclass instances of its parameters (at runtime too), so they're necessary.
[magnolia:scala3] 14 new commits
propensive/magnolia@fdb313e Draft for scala 3 - maphipropensive/magnolia@8b48345 Some further work on support for dotty - KacperFKorban
propensive/magnolia@2de6461 Interface for Scala3 changes - KacperFKorban
propensive/magnolia@9b61ea9 bump sbt-dotty version - KacperFKorban
propensive/magnolia@66b94dd bring back scala2 sources - KacperFKorban
propensive/magnolia@0ae9b9f
propensive/magnolia@0ae9b9f Docs and removal of mercator binary - propensive
macro implementations cannot have implicit parameters other than WeakTypeTag evidences
implicit def avroReader[T]: AvroReader[T] = macro Magnolia.gen[T]
[magnolia:main] 17 new commits
propensive/magnolia@fdb313e Draft for scala 3 - maphipropensive/magnolia@8b48345 Some further work on support for dotty - KacperFKorban
propensive/magnolia@2de6461 Interface for Scala3 changes - KacperFKorban
propensive/magnolia@9b61ea9 bump sbt-dotty version - KacperFKorban
propensive/magnolia@66b94dd bring back scala2 sources - KacperFKorban
propensive/magnolia@e5a27ba
propensive/magnolia@e5a27ba Update docs - propensivelegacy branch for the foreseeable future. ("Legacy" sounds a bit harsh, but I'm mostly trying to distinguish it from the latest version). Magnolia for Scala 2 isn't in any way "deprecated". 🙂
Hello, I have a question about TypeInfo.
Say I have a type class: Print[A]
And I derived an instance for a generic: (I have a manual instance for primitives, like String)@deriving(Print)case class Wrapper[A](value: A)
and then instantiate a value: Wrapper[String](“hello !”)
The type infö is something like TypeInfo(“Wrapper”, List(TypeInfo(“A”, Nil))
I was hoping the typeinfo for Wrapper would be TypeInfo(“Wrapper”, List(TypeInfo(“String”, Nil))
Q1: Is there a way of ‘materialising’ the type info, given the value ?
Q2: (back up plan), Is there a way of seeing that the type of the parameter (“hello”) is the same as the type parameter ?
@deriving is from Sam Halliday's Scalaz-deriving, right?
TypeInfos are derived, but IIRC, macros are rather lazy about what they evaluate, so A is probably the best we have at that point. In general, a type-parameterized Wrapper would have A inferred only on its construction, inferred by the type of value, and that would happen only after the macro has generated a tree and exited.
implicit ev: A =:= SomeType) to the combine and dispatch method definitions. That may prevent the macro-generated from typechecking if it can't find the implicits though.
combine and dispatch don't have to adhere to a strict interface in the object-oriented sense. They just need to be defined in such a way that the macro-generated calls compile. So extra implicit parameters or type parameters are fine.
Maybe if I say a bit more about what I'm doing it may help. Reify[A] is that actual type class I've defined, not Print[A].
Reify[A].reify(value: A) produces a string that should be the same as the code used to produce value. It's working fine for non generics, and it's fine for case classes where the type parameters can be inferred.
case class FooA
Reify[Foo[String]].reify(Foo(Some("hello")) produces Foo(Some("hello")
but
Reify[Foo[String]].reify(Foo(None: Option[String])) produces Foo(None).
If each param had a method to obtain it's generic type, so for
case class FooA
FooString ctx.parameters === Seq(
("a value", "String", "String", ...),
("another value", "String", "A", ...)
)
Then I'll be able to infer that A =:= String and produce the result I want.
East, fast, transparent generic derivation of typeclass instances – probably meant to be Easy, fast, transparent generic derivation of typeclass instances.
Yes, I forked magnolia and added paramTypeName to Param, and I have solved using that.
From param.typeName I have TypeName(, "A", Nil)
From the typeclass instance for that param I already have
TypeName(, "String", Nil), so it's easy to associate "A" -> "String", it was also easy to feed that back into the TypeName for the 'root' value. say TypeName(, "Foo", Seq(TypeName(, "A", Nil))) and get
TypeName(, "Foo", Seq(TypeName(, "String", Nil)))
With then allowed me to reify FooString as, erm: "FooString" !
:point_up: Edit: Yes, I forked magnolia and added paramTypeName to Param, and I have solved using that.
From param.typeName I have TypeName(, "A", Nil)
From the typeclass instance for that param I already have
TypeName(, "String", Nil), so it's easy to associate "A" -> "String", it was also easy to feed that back into the TypeName for the 'root' value. say TypeName(, "Foo", Seq(TypeName(, "A", Nil))) and get
TypeName(, "Foo", Seq(TypeName(, "String", Nil)))
Which then allowed me to reify FooString as, erm: "FooString" !
Why is it you don't have a good way to test performance anymore ? Is CI too variable ?