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. -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel