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

[luiz americo pereira camara]

2012/11/29 Graeme Geldenhuys <graeme at geldenhuys.co.uk>:
> Hi Luiz,
>
> First off, thanks for take the trouble it creating test projects.
>

Thanks for looking at them ;-)

>
> On 2012-11-29 02:59, luiz americo pereira camara wrote:
>>
>> 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.
>
>
> OK, there are quite a few things I consider wrong with your Test1
> application.
>
>  1) Nothing stops Michael from extending the IPFObserver interface to
>     include a GetObject function that returns a TObject reference of
>     the observer.
>     I have seen many such cases in the wild. Not sure if I agree
>     with it, but that is another story.

Yep but would be yet another type cast although Sven have concerns
about if is really possible

>  2) What exactly are you observing in Test1? What are you trying to
>     accomplish?

It's just to say that sometimes you have only an interface reference
(in the case IFPObserver)

In some of my code i have properties of an interface type like
IPageController. So i know what it does (or what is supposed todo) and
i'm not tied for any specific implementation or class.

In this case a IPageController can be a non visual component placed in
a form that controls the page behavior or it can be TTreeView or
TListBox descendant

>
>  4) If you change FChildren to TObjectList, then it can be observer.
>     Then simply attach observers directly to the Children property. That
>     way if you add or remove children, the observers are notified.

The example was simply a quick demo.
Think Children as private and not necessarily a TObjectList or TList,
just an structure that holds more than one object that can be observed
by the same observer.

BTW: the objective of Test2 is to show that it can be unnecessary
typecasts. In the example if Observer was IFPObserver no type casts
would be done when attaching child objects

>  5) I guess this depends on what you want to accomplish. But if you
>     first add children, then only call Initialize, then the observer
>     will never be notified that children was added to the list.
> It was actually hard to figure out what you are trying to accomplish
> with your test project. I think I'm still unclear of this. I'm seriously
> under the weather at the moment (bad case of flu), so that probably
> affects my judgement. So if I misinterpreted your Test project, please
> do let me know. In the mean time, I modified your test1 (see attached).
> The Observer now observes the Children List, and each Child - again, not
> 100% sure what you wanted to accomplish.

See above

There's a more concrete example about the duplicate typecast.

I'm developing a model manager that would be responsible to easily
create LCL forms/frames, html forms, LazReport reports etc with the
same set of data/models

Each project has a TModels collection with a TModel item
Each TMode item has a TFields collection with a TField item
Each TField has a unique Id managed per project
Currently to set the id of new Fields i have a circular reference
TField <> Project
My idea is to isolate TModel/TField to be independent of TProject
I can add a intermediate class to connect each other
But i could also takes advantage of Observer so i could observe the
Fields collection of each TModel to update the id when is added
The idea is add a FieldsObserver property to TModels and attach it to
each TModel

It can be done as today?. Sure. My concerns are

- I cannot define FieldsObserver as IFPObserver (the reasons why do i
prefer as it are above)
- Using FieldsObserver as TObject each time i attach/dettach from a
TFields there will be a type cast that i know before hand is not
necessary and could avoid.

In my proposition, is up to programmer decide if will use TObject or
IFPObserver in FieldsObserver, different from today that i'm tied with
TObject.

Different from what Michael stated in previous email, in my
proposition there would be no increase of interface usage in the
functionality itself. Just would be explicit to the programmer that
this feature requires a interface rather than now, that is hidden in
the implementation.

BTW: TField name is abbreviated so no clash with db.TField

Luiz