[fpc-devel] Tests of observer feature [was: Considerations about observer]

[michael.vancanneyt at wisa.be]

On Thu, 29 Nov 2012, luiz americo pereira camara wrote:

>
>
> Well i have at least two situations, with code that is already
> running, that the observer pattern would fit as i described.
>
> - I implemented a Wizard Page component where i can attach a page to
> any TFrame. Each page can be assigned as an instance or it can be
> created at demand when is entered. Optionally the TFrame (Observed)
> can implement a CORBA interface to communicate with the wizard
> controller (Observer). This same TFrame can be used elsewhere, e.g, in
> a configuration page, in this case, the wizard functionality will be
> ignored since there's no observer.
>
> I could use the native Observer support to simplify the interface,
> making easier implement.

I still do not see how this is forbidden by the observers as they work now.

>
> - I have a code that takes a TFrame and show as dialog with some
> configurable buttons. To communicate to inform of state changes i use
> LCL messages that is really cumbersome.
>
> I could use the native observer support also. So if something changed
> in the TFrame i could enable the save button or popup a dialog to save
> the changes. If this same frame is used every where the Notidications
> would be discarded since there's no observer

I fail to see how the current interface forbids this ?

> In the two cases one does not know about the other. What links is if
> the owner implements an interface or not and the implicit contract of
> this interface usage that is defined by the programmer. So i cannot
> simply call AttachObserver(Owner).

So you say, but you do not explain why not.

> Anyway, to me is clear that you wont change your mind regardless of
> the arguments i use since you are not willing to change your code that
> relies on it.

No, actually that is the least of my worries. 
It is an argument, not *the* argument.

The argument is:

I am not a fan of interfaces, and will avoid them like the plague when
possible. The current implementation makes absolute minimal use of them and
it works.

Your proposal goes against all that I try to avoid, meaning that if I do 
as you ask, I am in fact changing it to something that I will later try 
to avoid as much as possible ?

I am willing to do this for the sake of FPC in general, but then you'll 
have to convince me of the huge benefits this change will bring.

You now present a use case where you do not want to change your own 
implementation in order to be able to use Observer ?

When in fact you could most likely perfectly use it as it is (see the "as
TObject" elsewhere), or in the worst case slightly change your interface 
so the observer support can be used.

All you need to do is 'expose' the observer TObject (implicitly or explicitly). 
I hardly see how this compromises your interface/implementation separation, 
by definition it is a TObject anyway ?

So in my eyes, you fail to present a clear use case to show that
use of interfaces would actually be beneficial for the majority of 
intended use cases of observers.

Michael.