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 ?
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.
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 ?
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.
You now present a use case where you do not want to change your own
implementation in order to be able to use Observer ?
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 ?
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.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
