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

[Michael Van Canneyt]

On Wed, 19 May 2010, Joost van der Sluis wrote:

> 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)

And, you would end up copying the whole FCL, LCL: one without observer
support, one with it. It is obvious that this is not the idea.

Suppose I create a TStrings clone with observer support, it is useless:
the whole FCL and LCL use TStrings from classes. So in effect, my
implementation is sterile, since I cannot use it in any real situation
that I actually need and why I implemented observer in the first place: 
to be able to observe for instance the changes in TMemo.Lines or
TCombobox.Items. (and these are from real-world examples).

I agree that we must make sure all code that worked still works,
so the interface names and their calls should have some FPC 
specific prefix. "fpo" or so;

But as for the location for this implementation there is no 
alternative but to implement it in Classes, and, more
specific, in TPersistent.

There have been other changes/enhancements in the Classes unit that
are not delphi compatible, but which have never broken other code.
No-one objected then, I see no reason why this minor change is
so questionable. I think the benefits of the observer pattern 
in the classes unit outweigh the 'incompatibility' issues.

One could adopt the same stance for the Sysutils code, or, for one,
on the unix units. No-one ever did, and with good reason: there must
be progress in FPC; we don't want to keep running behind Delphi forever.
Compatibility: absolutely. But also: progress and enhancements !

Michael.