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) Ducktaping more on top of this is IMHO the worst of both worlds. Old stuff out of compatiiblity, but not entirely. If the status quo hurts so much, than start with a clean slate. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
