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

[Joost van der Sluis]

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.