This isn't necessarily a Scala question, it's a design question
that has to do with avoiding mutable state, functional thinking
and that sort. It just happens that I'm using Scala.
Given this set of requirements:
Input comes from an essentially infinite stream of random
numbers between 1 and 10
Final output is either SUCCEED or FAIL
There can be multiple objects 'listening' to the stream at any
particular time, and they can begin listening at different times
so they all may have a different concept of the 'first' number;
therefore listeners to the stream need to be decoupled from the
stream itself.
Pseudocode:
if (first number == 1) SUCCEED
else if (first number >= 9) FAIL
else {
first = first number
rest = rest of stream
for each (n in rest) {
if (n == 1) FAIL
else if (n == first) SUCCEED
else continue
}
}
Here is a possible mutable implementation:
sealed trait Result
case object Fail extends Result
case object Succeed extends Result
case object NoResult extends Result
class StreamListener {
private var target: Option[Int] = None
def evaluate(n: Int): Result = target match {
case None =>
if (n == 1) Succeed
else if (n >= 9) Fail
else {
target = Some(n)
NoResult
}
case Some(t) =>
if (n == t) Succeed
else if (n == 1) Fail
else NoResult
}
}
This will work but smells to me. StreamListener.evaluate is not
referentially transparent. And the use of the NoResult token just
doesn't feel right. It does have the advantage though of being
clear and easy to use/code. Besides there has to be a functional
solution to this right?
I've come up with 2 other possible options:
Having evaluate return a (possibly new) StreamListener, but this
means I would have to make Result a subtype of StreamListener
which doesn't feel right.
Letting evaluate take a Stream[Int] as a parameter and letting the
StreamListener be in charge of consuming as much of the Stream as
it needs to determine failure or success. The problem I see with
this approach is that the class that registers the listeners
should query each listener after each number is generated and take
appropriate action immediately upon failure or success. With this
approach, I don't see how that could happen since each listener is
forcing evaluation of the Stream until it completes evaluation.
There is no concept here of a single number generation.
Is there any standard scala/fp idiom I'm overlooking here?
