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

[luiz americo pereira camara]

2012/11/29  <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 ?


It does not forbids. It's just an example of the need to check if a
object implements an IFPObserver before attaching it.
You have said that there's no real life situation you need to do this
check since the programmer should know that implements always before
hand


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

It can crash since not necessarily owner (e.g. a simple TForm) will
implements IFPObserver?


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

You would not be forced or induced to use an interface it would be optional.
Other programmer can have a different view/need of you. It's up to him
decide what to use.

BTW: did you read my comment about observer method not being public?
By the currently implementation to attach a Observer to a TPersistent
the programmer is _forced_ to use an interface contradicting what you
said above.

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

OK

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

As i said Observer would simplify the usage, so i'm willing to change my code.

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

I know what to expect when i see an IFPObserver property but not when
i see an TObject (although i can guess by the name).

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

Ok.

Thanks for taking your time reading my comments

Luiz