Tuan Kiet
06/15/2019, 1:27 AM() -> Unit
is Function0<Unit>
karelpeeters
06/15/2019, 6:56 AMTuan Kiet
06/15/2019, 1:18 PM()
karelpeeters
06/15/2019, 1:23 PMTuan Kiet
06/15/2019, 1:26 PM() -> Unit
is Function0<Unit>
karelpeeters
06/15/2019, 1:30 PMFunction1<LiveNavigator, Unit>
.Tuan Kiet
06/15/2019, 1:43 PMFunction1<LiveNavigator, Unit>
is (LiveNavigator) -> Unit
not LiveNavigator.() -> Unit
karelpeeters
06/15/2019, 2:21 PM(X) -> Unit
to something that expects a X.() -> Unit
and the other way around, in the end it's all syntax sugar.Tuan Kiet
06/15/2019, 2:24 PM(LiveNavigator) -> Unit
will make LiveNavigator
as it
while LiveNavigator.() -> Unit
make LiveNavigator
as this
. I have seen a lamba have both it
and this
as the same time (maybe something like LiveNavigator.(Int) -> Unit)karelpeeters
06/15/2019, 2:25 PMit
vs this
is just a name, there's no actual this
object that the function is being invoked on. This is what I mean by "syntax sugar". The second example function then becomes Function2<LineNavigator, Int, Unit>
.Tuan Kiet
06/16/2019, 12:00 AMFunction2<LineNavigator, Int, Unit>
I don’t get this
as LineNavigator
and it
as Int
(but get lamba { navigator, value -> } instead
) how can I do this?karelpeeters
06/16/2019, 7:56 AM() -> Unit
notation instead. Why do you want to avoid it?Tuan Kiet
06/16/2019, 8:11 AM(LiveNavigator) -> Unit
but not with LiveNavigator.() -> Unit
karelpeeters
06/16/2019, 8:55 AMFunction1<X, Y>
more explicit then (X) -> Y
? The latter is way more readable.Function1
interface as an implementation detail you shouldn't worry about.