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

[michael.vancanneyt at wisa.be]

On Thu, 29 Nov 2012, luiz americo pereira camara wrote:

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

Yes. I still do not see how your example shows this ?

Your wizard knows it can observe. It attaches itself to the frame.
The code frame does not need to know the observing object ?

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

Who takes the decision to observe or not ? The TForm, I assume.
Somewhere the decision is made. In this location you will necessarily know
who will do the observing, and you will know it has 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.

Eh ? 
I would need to do a AttachObserver(MyObservingObject as IFPObserver) everywhere 
where I want to observe, instead of AttachObserver(MyObservingObject).

That is hardly 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 already fixed that. I also fixed the sender problem. 
In my cases I always had (Sender=Self).

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

OK.

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

I am sorry, but I really still do not understand your problem with the interface.

Contrary to what it may look like, it is not so that I am dead set 
against such a change. However, to me, your change presents a serious 
disadvantage. Therefore I expect you at least to show to me that there 
is a substantial need or benefit in this for all of us.

Because till now I simply do not see the need or benefit...

Michael.