search

guigarage / ObserverPattern

Basic Java observer API
Apache License 2.0
7 stars 7 forks source link

Listen and set #7

Closed hendrikebbers closed 7 years ago

hendrikebbers commented 7 years ago

see #3 for description

hendrikebbers commented 7 years ago

@HanSolo @miho @hastebrot would love to get some feedback :)

hendrikebbers commented 7 years ago

I think the method must be renamed...

hastebrot commented 7 years ago

onChangedAndCall() looks like we should break this method into two methods. What about replay(1).onChanged() or autoConnect().onChanged()? Having only onChanged() would increase uniformity (which is also a problem/quality indentified in [1]). In contrast this could maybe lead to lower discoverability in the IDE (typing on... gives us the methods we need to handle the changes).

[1] Maier, I., & Odersky, M. (2012). Deprecating the Observer Pattern with Scala.React (No. EPFL-REPORT-176887). https://infoscience.epfl.ch/record/176887/files/DeprecatingObservers2012.pdf

I would probably even go further with uniformity and introduce both

values().subscribe(newValue -> newValue)
changes().subscribe(change -> change.newValue)

i.e. instead of 

onChanged(change -> change.newValue)

we have 

changes().subscribe(change -> change.newValue)

An issue I didn't thought about (yet) is, how this fits into the existing java.util.EventListener and co.

I also like to apply this idea on e.g. ObservableList and use it for additions(), removals() which could both return an Observable (related to CollectionChange in #1).