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

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> > 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.

You would duplicate it, but not copy it. If you abandon compatibility, do it
right.
 
> Suppose I create a TStrings clone with observer support, it is useless:
> the whole FCL and LCL use TStrings from classes

I know the tradeoff yes. But a bandaid like FPC only solution does not solve
anything either AND has compatibility issues.

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

Yes. And the next person wants to iterate over tstrings with an iterator, or
let them also support IEnumerable and IVector, and therefore let it inherit
from TInterfaceobject (that's the thing that I would copy from Java btw,
don't care about observer pattern).

I also assume there is not a lot of code inserted in nearly every method to
detect change and call the observers too?  Not all modifications are about
interface changes :-)

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

While that solves at least the worst compatibility issues.  I still think it
is a weak and redundant attempt. 

If the current situation is so horribly dire that you can't really do
without it, such a bandaid is not enough.

IMHO this is some not terribly thought through bandaid to fix some accute
problem, and that sets a bad precedent.

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

The alternative is to reconsider the need for this.

> There have been other changes/enhancements in the Classes unit that
> are not delphi compatible, but which have never broken other code.

Those were minor enhancements. Not support for new concepts.

> so questionable. I think the benefits of the observer pattern 
> in the classes unit outweigh the 'incompatibility' issues.

I don't think there are any benefits to making those classes even more
complicated then they already are. 
 
> 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.

I do not really have the feeling this is a grand move forward. It sounds
more like scratching some acute itch, rushed to be in the codebase before
anybody notices.