In wire-android we often made decisions based on comparison of values of different signals. It looks something like this:
for {
a <- signalA
b <- signalB
} yield
if (a == b) doThis()
else doThat()
or:
signalA.zip(signalB).map {
case (a, b) if a == b => doThis()
case _ => doThat()
}
In short, a lot of logic was based on comparing signals values, creating a boolean signal, and then doing something with it. For that I could introduce a compare method:
Here in signals3 I already implemented methods and and or in Signal - they can be used only if the signal is of a type that can be used as a boolean. I can develop it more:
and and or in Signal for more than two arguments (up to five? six?)
xor for two arguments
not for both Signal and EventStream
operators aliases (even compare could have an operator alias ===):
(signalA === signalB).map {
case true => doThis()
case false => doThat()
}
In wire-android we often made decisions based on comparison of values of different signals. It looks something like this:
or:
In short, a lot of logic was based on comparing signals values, creating a boolean signal, and then doing something with it. For that I could introduce a
comparemethod:Here in signals3 I already implemented methods
andandorinSignal- they can be used only if the signal is of a type that can be used as a boolean. I can develop it more:andandorinSignalfor more than two arguments (up to five? six?)xorfor two argumentsnotfor bothSignalandEventStreamcomparecould have an operator alias===):nand?nor? Can a signal be a transistor?