Re: [Rails-devel] Rails2.0: States and Models as Observables

[Stefan F. <ste...@we...>]

Brett,
thanks for your comments. See answers below.
Stefan

>>
>> I consider the java.util.Observable/Observer implementation is not a
>> perfect fit for Rails, I preferred to write my own instead.
>
> Can you expand on this a bit more? What are the limitations that your
> version overcomes?
>

In my view (at several more competent others) it is not as easy to use 
as it can be with your own implementation.

The general issues I have, are that is a) non-generic (if one has to
use a data object at all), b) confusing to use (you have to do both 
setChanged and notifyObservers, there is no forcedNotification) and c) 
the update method of the Observer always always requires one Observable 
and a data object (which however can be null).

More details see e.g.
http://www2.sys-con.com/itsg/virtualcd/java/archives/0210/schwell/index.html

The rails specific issue is that the list of observers in 
java.util.Observable is not implemented as state variable, so it is not 
undo/redo-proof.

In general I believe that design patterns should not have a language 
implementation, as they are suggestions for good coding, not recipes for 
good coding. Thus you should incorporate the idea into your own code.

An excellent implementation (in terms of generality) is the one from 
PerfectJPattern: http://perfectjpattern.sourceforge.net/dp-observer.html
however it is easy to agree that in almost all cases it is a complete 
overkill.

>> However the Observer interface could potentially change, as I am stil
>> working on the needs and constraints of the existing GUI.
>>
>> Currently an Observer only provides an update(Observable obs, String
>> text) method. The latter argument provides a text update for the
>> standard cases.
>>
>> I am wondering if I should add a proxy approach, such that the Observer
>> can specify a function which has to be called that can be specific for
>> each Observable observed. Or if I should be more restrictive and allow
>> each Observer to observe ONLY one observable, thus dropping the need to
>> specify the Observable in the interface method.
>>
>
> In general, I would support the more flexible design. However, I'm not
> certain of the use cases here. Can you give some examples on why we'd
> prefer one design over the other?

I cannot give concrete examples yet, as I have not started to change the 
code seriously. However I am getting closer to the opinion that 
restricting that one observer can only observe one observable (so N:1 
from observers to observables) is a good idea: The consequence is that 
if an Observer wants to observe several Observables at the same time, 
this could be realized by creating a specific Model for that Observer.
And that is exactly the function of a Model that it combines the effect 
of several other observables (states/models).

As I prefer Python over Perl I usually prefer the easier design over the 
flexible design ;-)