[fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Graeme Geldenhuys graemeg.lists at gmail.com
Wed May 19 18:52:36 CEST 2010

On 19 May 2010 17:36, Marco van de Voort wrote:
> I don't see why the observer pattern is needed at such low level any more
> than 20 other little handy features that each would be a lot easier if they
> just had a field/property in the baseclasses.

Marco, not trying to be rude, but please take a step back, see the big
picture and listen to yourself. You sound totally ridiculous - it's to
the point of being funny.

I don't know what software, if any, you write for a living but clearly
other developers here see a benefit of "enhancing" the base classes. I
can easily list a arms length of benefits in having the observer
available in base classes.  Just look at Java too see how popular the
Observer can be. I'm pretty confident .NET would be similar. You seem
to have a bit of tunnel vision - not seeing the big picture.

> It is the beginning of the end.

Oh I get it! So do you want to be the person to tell
Borland/Embarcadero that they should rather have re-implemented the
whole RTL and created a totally separate hierarchy when they
introduced a few new properties in the TObject recently. Because Marco
doesn't agree with making low-level changes even if it means
improvements down the line.

Oh, and should I mention that their "little" change, which was
implemented in FPC for compatibility reasons, broke our company's
application, fpGUI toolkit and caused problems in the tiOPF framework.
That's just three projects I know of - I wonder how many other
projects broke because of that. Yes if though our applications
couldn't compile any more, it was a small thing to fix.

The Observer we would like to introduce should have little impact as
well, and IF issues occur in developers own software, it should be
easy to fix, or they can remove their Observer implementation and use
the one that is included as standard in the FPC's RTL.

> It is always only a few places. But what you are effectively doing is
> opening the gate. If we allow this, the rest is only a matter of time.

Oh, we are getting very dramatic now.   :)

>  If you want to be the
> library designer, do so, and do it well instead of applying bandaids to the
> current classes.

And if you want to be a "compatibility freak" you are free to start
your own fork of FPC - nobody is stopping you. Or simply switch to
Delphi and be done with it.

We are trying to improve FPC!! Just like Borland/Embarcadero improved
Delphi by introducing COM/Interface somewhere between D2 and D4,
Actions in D4, Frame in D5, language extensions (unicode etc) in D2009
etc... They did that all without creating a totally new RTL hierarchy
even if it mean breaking some old code.

  - Graeme -

fpGUI - a cross-platform Free Pascal GUI toolkit

More information about the fpc-devel mailing list