Deprecate the whole thing

[milibopp]

@Moredread @coldfix @DanielSank

Pinging everybody who might be still interested in this.

By now, I feel like using the raw observer pattern like this is actually a bad idea and one should go for something more reactive, e.g. RxPY. Thus, I am inclined to just deprecate this module entirely, as in put a note on top of it. I don't think anybody is actually using it, but hey why not make it clear right away.

[Moredread]

But think of all the users!!!

No, actually you are right. ^^ 125 commits in XD

[DanielSank]

Interesting. Because I wrote my own small version of the observer pattern, and because I stand to learn something: why is the raw observer pattern worse than "something more reactive"?

[coldfix]

Don't worry, it's because they hippsters about functional programming:D They learned that there is something cooler than OOP and suddenly they think nobody can use OOP for anything anymore:)

[DanielSank]

@coldfix

hippsters about functional programming

Isn't the world "brogrammer"?

But seriously, this isn't the first time I've heard that generating webs of observer-style callbacks can be painful, and that some kind of "reactive" thing is better. You once gave me a fantastic reference to a Google Clean Code talk about using polymorphism instead of if-statements. Any chance you have a nice reference about this reactive issue? It would be nice to at least understand what everyone's talking about with an example that doesn't require learning javascript and some god-forsaken web framework.

[coldfix]

Yeah, that's right, it can be painful. I'm not all to familiar with FRP, but @aepsil0n built a library for rust and there is some paper referenced in the docs which might be of interest. Apart from that, he certainly knows more than me about this..

[milibopp]

o.O "hipstering about FRP."

Yeah, that might be a little academic and having to learn Rust is not necessarily easier than JavaScript frameworks.

I think to paraphrase the general idea: common pain points using the observer pattern like we've done with this library, are, that you quite often have no idea, where your events come from, in what order they arrive or how a given event is processed. It gets kind of hard to track, because there all these implicit subscription relations.

FRP basically gives you a data type (can be a dynamic, too, of course), that represents a stream of discrete events occuring over time. Can be visualized like this (time goes to the right):

my_stream =
  >--[3]-------[4]---[1]--[0]-------[17]---[6]--->

Then you have a few primitives, like map applying a function to each element

my_stream.map(x → x * 2)
  >--[6]-------[8]---[2]--[0]-------[34]---[12]--->

You can also filter, fold, merge, etc. streams. There's a bunch of primitives that let you compose these streams. In essence, as with a lot of functional programming stuff, it is much nicer to test, refactor and maintain than the OOP-like observer approach.

Personally, I like this marbles website a lot to get a feel for the API.

Note, that there are less radical approaches doing reactive programming with stateful OOP-like components instead of purely functional immutable data structures. The essence here is, that you end up with a unidirectional data flow, i.e. all the events are propagated in one direction instead of going back and forth.

Hope that helps a little…