On Wed, 2010-05-19 at 16:59 +0200, Marco van de Voort wrote: > In our previous episode, Michael Van Canneyt said: > > > I don't care about such schemes being used in code that is not Delphi > > > compat > > > (fpgui, fpweb etc). I wouldn't like it for the database components or LCL > > > components though. > > > > The problem is that this pretty much rules out the use of the observer > > pattern, because you need to subclass every existing class that you want > > to work with, which is exactly the problem that we're trying to solve in > > the first place. To be effective, it needs to be in the base classes. > > Yes, so it should IMHO be kept outside the current hierarchy, but using a > new hierachy with a new baseclass (only one level higher than object) Those > are > hopeless outdates anyway, and adding even more paradigms to them is no > solution. > > > I have an implementation in place, which doesn't affect too much the > > existing classes: it adds 1 public property and one private method; > > There is no impact on code efficiency. > > Sure. Today this, tomorrow that. I still think this is a bad idea. > > > I am all for systems to reduce namespace pollution and minimalizing impact > > for the users, but maintaining the status quo forever is also not an option. > > System quo what where? The current libs are mainly about compatibility, and > because of that e.g. many language extensions from D4+ were never introduced > into the system (which is why e.g. the LCL uses TStrings instead of a > minimal interface needed to draw)
I think I would agree with you if it was true that most libraries are about compatibility. But if I want to replace TComponent/TControl/TPersistent with newer versions, I would start copy-pasting them. And there would be only a few changes. (I can't think of any now, expect for adding the ability to use the observer pattern) Joost. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
