Open JorgeCastilloPrz opened 4 years ago
@JorgeCastilloPrz I've been checking this out a bit, what do you think about something like this:
first()
, second()
, etc, extension functions, as you've said, there's mountains of functions this adds for every type when really, it's only ever used for a handful of typesFirst
, Second
, etc, data class constructors public, this gives a generic way to construct an instance of the Coproduct still, maybe even move them to be nested instead of top level classes along side the Coproduct sealed class definition to add extra namespacingtypealias
s such that it could generate extension constructors on only the types that are actually part of a Coproduct, like:
// Code the user would write
@CoproductConstructors
typealias Result = Coproduct3<GenericFailure, Failure, Success>
//Code we could generate fun GenericFailure.asResult(): Result = Coproduct3.First(this) fun Failure.asResult(): Result = Coproduct3.Second(this) fun Success.asResult(): Result = Coproduct3.Third(this)
This would largely reduce the footprint for constructor methods and still allow for some easy to use syntax, but at the cost of having to add the annotation processor if you want to use it that way. Getting an annotation processor to work on typealias is somewhat complicated, but seems possible, so I wanted to get feedback before I tried anything too in depth. I'm also unsure if something like Arrow Meta could solve this in a better way?
What version are you currently using?
0.10.2
What's the issue?
We've been using Coproducts since long ago, and they already got a big refactor at some point because of this. Looks like it's still happening though. Working with coproducts makes the indexer work astoundingly slow because of the amount of public methods available in the api. I've got 32 GB RAM and it's still remarkably slow.
It would be nice if we could find a way to scope those differently or something so the indexer and the type inference system don't need to work so much.