Signal.filter

[dylemma]

Some discussion in #59 led to talk about Signal.filter, which ended with a question: what needs to happen to a Signal when you filter it?

I posted:

Filtered stream ignores unaccepted changes

[parent] 1---2---3---4---5---
[evens ] ----2-------4-------

But this is bad because a) it leaves the filtered stream with the possibility of having no >initial value and b) it doesn't make a ton of sense in terms of signals.

Filtering a stream results in a Signalof Options

def filter(f: T => Boolean): Signal[Option[T]]

This kind of works, but it's different from the usual semantics of filter, and that could be >confusing.

Signal's value is always optional Where there exists some ADT for the signal's now, along the lines of

sealed trait State[+T]
case object Undefined extends State[Nothing]
case class Defined[T](value: T) extends State[T]

And where a filtered signal's parent changed to a value that its filter didn't accept, its own value would go to Undefined

I am of the opinion that using the State data type under the hood is the best idea, though it would bring about some necessary changes:

//in the Signal trait...
def changes: EventStream[State[T]]
def definedChanges: EventStream[T] = changes collect {
  case Defined(t) => t
}