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

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

Therefore your test to see if A has the observer interface is simply redundant.

Anyway, all this is why I think that using an interface-based API
has no value in this case. There will be an object somewhere that 
you will have written to do some observations and act on changes.

All I require is that you use the actual object in the API.
It's guaranteed to be there anyway.

Michael.