We also shouldn’t implement a generic JsonSemigrou...
# helios
a
We also shouldn’t implement a generic JsonSemigroup because how would you combine a JsDecimal(“1.33”) with a JsString(“abc”)?
a
I suppose in that case the JsString Semigroup would prevail but to simplify this I would say to match that both Json are the same type of Json, if not we don't combine anything
a
What happens in the case when the two Json subtypes are not the same? Which one should we return?
a
The original one
but we can combine all the JsonNumber subtypes at least
a
My problem with that one is that it doesn’t really make sense to add two JsNumbers together.
Why not subtract them? It’s a bit weird.
Cannot really see the use-case for it.
the interface is ok, i guess, for the merge.
but the implementation should be done by the user of the library.
as it’s really specific to the use-case.
a
realize that we are defining the default monoids so obviously the user can define and use their owns but the default ones should always sum the values
a
sure! as you’d like. I will come back with a commit.
what should we do btw with JsNull?
the companion function generator won’t work.
a
fun JsNull.monoid(): Monoid<JsNull> = TODO()
doesn't show any error to me