Listener/Observer pattern, or the Scala Reactives approach?

[Jacob Biggs]

After having my mind blown by this paper:

http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

I was wondering if this project should be using Reactives instead of
listeners to VASTLY simplify event handling, and well as remove the
irritation that is inversion of control. I can see how 'Deprecating
the Observer Pattern' would be extremely valuable to this project.

[philip]

Conversely, please don't make things too complex. Simple and straight
forward is attractive.

[Jacob Biggs]

In what way are Reactives not simple and straight forward?

[Hicks, Matt]

Can you give an example of how one might "react" to the size of a Component changing?

I'm very open to the idea of using Reactives, but unfortunately when I read this paper several months ago I could not figure out a way to apply it that would be as powerful and as simple as the event system I designed.

[Jacob Biggs]

I am not suggesting that Reactives replace events, since they don't. Rather

than having listeners that you have to add to structure that would throw

events, you simply use a Reactive on that independent data, which would

then emit events each time its value changed, in turn re-evaluating all data

dependent on the variable contained in the Reactive. Each reactive has

an event stream, as explained in the paper.

Say the dimensions of the outer component are dependent upon its inner

components (probably more of a given). If whatever data model you were

using needed to redraw the component when the size changed, and the size was

a Signal, say inner.size, and the outer was also Signal, this.size,

and the body was defined as { someConstant + otherVaribles + inner.size() },

the value would be re-evaluated when inner.size threw an event to its

stream of its value changing, thus this.size() would also throw an event.

The redraw method could be in a Reactive.loop that continuously calls

next( this.size.changes ), the event stream of this.size. Thus, the visual

component would always reflect the most current size data.

This is just a brief example of one style of implementing Reactives vs

listeners. My thoughts were just getting rid of adding listeners to objects,

and being able to build dependency hierarchies that always hold the

correct values when based on time-varying variables.

It believe Reactives would also make user input easier and more

coherent to manage and debug, in light of the Adobe example at

the beginning of the paper. 

[Hicks, Matt]

So something along the lines of reactions in the Scala Swing wrapper?

Like this:

    selection.reactions += {
      case ListSelectionChanged(e, range, live) if (!live) => selectionChanged()
    }

What benefit does this provide over:

    selection.listeners += EventHandler(handleSelectionChanged, ListViewSelection.Events.SelectionChanged)

The nice thing about what I'm intending with the next iteration of Events in Sgine is that you get static validation on event types associated with an object so it won't compile if you try to use an event type that is not thrown by the class.  I found reactions in Scala Swing to be a bit frustrating in this regard.  Definitely I'd be open to considering using partial functions as a way of reducing the amount of code necessary but I don't see the other benefits.

[Jacob Biggs]

Not exactly, you are still trying to reverse control.

observe(selection)(handleSelectionChanged)

[Hicks, Matt]

How does observing occur but to listen on the instance itself?  Or is there a general bus that observers connect to and events are published to?

[Jacob Biggs]

Well, anything that publishes events does so to a stream in the Reactive framework, usually .changes I believe. So selection as a Reactive has that stream as well. So I believe the observer using observe([Reactive]) executes by calling next([Reactive].changes), which suspends its activity until a new event is published to that stream.

[Hicks, Matt]

I guess I don't follow what benefit that provides?

[Jacob Biggs]

The observe is just a library layer to help a smoother transition from

observers to data-flow/reactive programming. I guess I will need to

make two versions of the same program, one with listeners, the other

using some form of Reactives so you could see the benefit.

[Hicks, Matt]

That would be appreciated....I'm definitely open to the idea if it benefits the architecture of the framework.

[Jacob Biggs]

It seems that Scala.React, in its current, has yet to be pushed to a public repository.

I can only find access to a snapshot that was posted for download around the time of

the paper's publication. Through the power of Google I have learned that he (Ingo Maier,

the creator of the framework) 'should' be pushing it to a github repository 'soon', though I am

not certain. 

I cannot even pretend to know as much as he does about FRP and how

to implement it elegantly in Scala, so I shall wait till some sort of formal release (hopefully

soon), as becoming a maintainer of the snapshot his framework is far too big of an

undertaking for me at the moment (and quite pointless if he is going to release it officially,

possibly even as part of the main Scala distribution).

Rest assured, though, since it seems one of the main considerations/bases of the framework

is the ability to incrementally "port observer-based code to a data-flow programming model,"

making the process of switching to, or adding the option of, FRP in future Sgine releases

a much more realistic endeavor.

[philip]

Scala React on Github https://github.com/dylemma/scala.react

[Hicks, Matt]

Nice, do you see any benefits to applying this in Sgine that isn't already covered by the event system?