On Wed, 19 May 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
So - let's try another approach which may prove more constructive:
What are your proposals to get some kind of observer pattern
implemented so it can be applied consequently throughout the
classes of the FCL and LCL, without duplicating all code or
subclassing all existing classes ?
First: I don't see an urgent need for such draconic measures.
Second: I don't see a good solution, exactly because the whole framework was
not designed for this.
E.g. an Observer pattern typically uses interfaces, and interfaces are not
designed into the framework.
I am not interested in the actual implementation of the observer
pattern, just the means by which you think we can 'inject' one.
Please don't bother questioning the need/desirability of
this feature, consider it a given.
And that you call "constructive" ?
Sorry, I'm just trying to restrict the discussion to technical matters;
Maybe I phrased that not optimally.
It's not because you don't see a need, that others don't have it;
there is no point in discussing that, we will never agree on that. Just like I
don't discuss religion with people.
But anyway, I don't see any sane solution to inject it. Including proposed
ones modifying base classes.
That is the whole point. If you want this, start over, and do it properly.
That is an impossibility, since then we cannot use it in the FCL/LCL, which
is one of the requirements:
I need a solution that works with current GUI, current libraries and
whatnot. What you propose is re-doing the work of 10 years, which is
obviously not feasable.
I fully agree with you that it may be desirable, but practically, it is not
feasable, since then we must throw away tried and trustable codebases. I am
even prepared to do work on designing and implementing
such an alternative scheme. But I also need a solution that works with
the current codebase.
So please propose something else, something you concede is not the optimal
solution, but which you are prepared to accept, lacking the
optimal solution.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
