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

[luiz americo pereira camara]

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.

The option of using a interface reference instead of TObject is valid
and has some advantages like implementation decoupling and making
clear what the programming contract is by the declaration itself,
i.e., if i have a Observer: IFPObserver property i know what to expect
from it different from Observer: TObject
It's possible to use a specialized class but it will create a
dependency to a specific implementation

In my proposition, the programmer could use a TObject or a Interface
reference such cases, without any overhead.

Test2
This test shows the duplication of typecasts when adapting Test1 to
match the current observer implementation.

ObserverObj is tested/casted to IFPObserver 1 + 2 * Children.Count
In the example 7 times. Yes the same test is done 7 times.

In my proposition, it could be implemented (test1) with only 1 typecast

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.

In the current implementation the same test is done twice, one in
caller and another in the callee

In my proposition there would be only one test (caller)

So, i hope i made my points clear and exemplified. Although the
examples are abstract they derives from a concrete example like having
using a TForm/TFrame with a Observer property that would be
responsible to attach the Observer for some child controls.

The change is simple with a leaner implementation, although breaks
interface. This fact is minimized since it's the first public fpc
release with this feature

PS: The main objection by Michael seems to be code that relies on the
current interface. The proposed change needs only to change as the
argument is called without any logic change.

Luiz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObserverTest1.lpr
Type: application/octet-stream
Size: 2350 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20121128/11e432e4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObserverTest2.lpr
Type: application/octet-stream
Size: 2334 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20121128/11e432e4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ObserverTest3.lpr
Type: application/octet-stream
Size: 717 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20121128/11e432e4/attachment-0002.obj>