[fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?
Graeme Geldenhuys
graemeg.lists at gmail.com
Thu May 20 00:57:15 CEST 2010
On 20/05/2010, Henry Vermaak wrote:
> enough technical basis, you will convince people. Like Linus says,
> talk is cheap, show me the code.
You are welcome to look at the tiOPF code.
http://sourceforge.net/projects/tiopf/
I also attached a simplified example to my previous reply to Macro and
code to show how it would attach to a base class and how to use it.
Talk IS cheap, so see the code. :-)
> disagreeing. The point was that it opens the door for a lot of other
> (perhaps questionable) stuff to weasel its way into the base classes
With that we should ban all modifications to FPC code because it might
introduce bugs or break something. Pointless! Why not handle each
"future enhancement" on a case by case basis IF they are ever
suggested, and not simply ban all enhancements on a "what if"
scenario. I think Michael and I have given sufficient benefits to
this idea, and seeing that nobody else has proposed a better
alternative (and reimplementing the RTL, FCL, LCL, fpGUI is *not* an
alternative), I see no reason why this cannot be added.
> Anyway, I do hope that there is a feasible to implement this, because
> the observer pattern is very powerful.
I'm confused. One minute it sounds like you are saying no it's a bad
idea, then the next paragraph you say is this is a good idea? :)
Anyway, review the code I supplied earlier and what is available in
tiOPF. Even run Demo 21 of tiOPF to see how a complete Address Book
application is implemented using a database and standard components
(LCL, VCL or fpGUI) and never does it need db-aware components. Every
component on every form uses Observer, and thanks to the Mediator
design pattern the communication is a two-way street.
--
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
More information about the fpc-devel
mailing list