-
-
Save ileasile/1016cf09608df8f9b7f4cfe2d64625f6 to your computer and use it in GitHub Desktop.
Thanks! Parametrized version is below. It indeed makes some lambdas easier to write
import kotlin.time.Duration
class Frame<T>(
val delayBefore: Duration,
val content: T,
)
fun <T> ANIMATE(frames: Iterator<Frame<T>>)
fun <T> ANIMATE(sequence: Sequence<Frame<T>>)
fun <T> ANIMATE(iterable: Iterable<Frame<T>>)
fun <T> ANIMATE(firstFrame: Frame<T>, nextFrame: (Frame<T>) -> Frame<T>?)
fun <T> ANIMATE(nextFrame: () -> Frame<T>?)
fun <T> ANIMATE(delay: Duration, iterator: Iterator<T>)
fun <T> ANIMATE(delay: Duration, sequence: Sequence<T>)
fun <T: Any> ANIMATE(delay: Duration, nextValue: () -> T?)
fun <T: Any> ANIMATE(delay: Duration, seedValue: T?, nextValue: (T) -> T?)
fun <T> ANIMATE(delay: Duration, iterable: Iterable<T>)
fun <T> ANIMATE(framesCount: Int, delay: Duration, frameByIndex: (index: Int) -> T)
Can one of them with functional parameters be with inline
modifier? Since they only serve delegating role, it may redice them without warmup
We don't actually need type parameters in any of the overloads except (firstFrame,nextFrame)
and (seedValue,nextValue)
. They will just cause unnecessary inference problems with unclear errors, if user types something wrong or too complex, and they provide no actual benefit. We can just use Frame<*>
, Any?
and Any
.
Also, I suggest declaring Frame as class Frame<out T>(...)
.
True, agree with the above. *
and Any?
looks right as a broadest spectre
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I suggest to add a type parameter here:
This way the user won't need to write
it as Long
and such.An extension of that idea would to be to make
Frame
parameterized:This way me may have this:
And
Frame<*>
in all other overloads. But this may be a bit over-engineered.