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

[luiz americo pereira camara]

2012/11/29  <michael.vancanneyt at wisa.be>:
>
>
> On Wed, 28 Nov 2012, luiz americo pereira camara wrote:
>
>> Given the considerations i did about the observer feature, here are
>> some simple projects that supports my concerns and therefore the
>> request i made to change the interface of two functions.
>>
>> Test1
>> As is today, if you have a reference to a IFPObserver is not possible
>> to use it to attach to, e.g., child objects. This occurs because AFAIK
>> you can't get a TObject from a interface reference.
>>
>> This limits the programmer choice to use a TObject in such situations,
>> in this case the Observer property.
>
>
> All objects in memory descend from TObject, so this is not a problem.
> COM provided objects are not supported. That would require COM interfaces.
>
> I have looked at your tests. They are IMHO rather theoretical and will not
> happen in real life. I can think of plenty of things that will not work even
> with TComponent or TObject. That doesn't mean they will happen.
>
> Your 'problem' is that you store only interfaces for objects that will
> observe. Indeed, this is a programming model I do not care to support *for
> observers*, because I  do not think it is likely to happen in real life
> situations.

> I explain this below.
>
>
>> Test3
>> Pretty simple: if you don't know if a TObject descendant instance
>> implements a IFPObserver (most cases) you have to do a check before
>> attaching to a IFPObserved otherwise an exception is raised.
>
>
> Let me get this straight:
>
> What you say is that you get from somewhere an unknown object (or an
> interface) and just decide to let it observe another object ? For what ? For
> fun ?



> That is a very strange argument. You don't "accidentally" observe.
> It is also not true that all objects A that have the IFPObserver interface
> are suitable to observe a particular object B.
>
> You observe for a purpose. I'll say even more: in most cases your observer
> will be written to specifically observe the observed class.
>
> You will not let object A observe object B for no good reason.
> Observing introduces an overhead. For this reason alone, you should not
> 'just observe'.

>
> A will observe B in order to react on changes that B reports,
> and A will act on these changes. In almost all cases, A will have specific
> knowledge about B: even if it is just that B has a published property named
> XYZ.
>
> So you will know in advance that when attaching A to B, that A will have the
> IFPObserver interface.


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 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

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).


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.

The alternative i proposed does not forbid the current usage pattern,
just add an option with possible performance benefits with no, or very
small, costs.

Generally now, it's up to the programmer takes what way best fit his
need and if a pattern is not used by a programmer, how good or
experienced he is, does not mean there are not valid usage scenarios.
This is even more true with new stuff that still not exposed for a
wider audience. I won't discuss this more, the arguments are there to
anyone judge.

BTW: Graeme already pointed, that the Observer methods should be
public. Does not makes sense to protect methods that are exposed by an
interface. You can just do (APersistent as
IFPObserved).FPOAttachObserver.  And yes, i have real life examples
that should be useful.

Also in TPersistent.FPONotifyObservers you should not be using ASender
in Obs.FPOObservedChanged?

Luiz