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

[Sergei Gorelkin]

Graeme Geldenhuys wrote:
> 
> Because many of the classes we want to observe descend from
> TPersistent. So it make sense to put the basic workings of Observer
> there, and then descendant components will decided what must trigger
> notifications.
> 
> Also we couldn't implement Observer earlier in FPC because FPC did not
> have the required features to do it. Now that Interface Delegation
> works for Corba-style interfaces, we can move to the next step.
> 
> 
>> And either way, you definately need a clean separation of concerns.
> 
> The bulk of the Observer pattern is implemented in a separate class,
> we than bolt that onto TPersistent via interface delegation.
> TPersistent will then implement the IObserverable (or whatever it will
> be called) interface. And not we are talking about Corba-style
> interface, so there is NO reference counting to worry about.
> 
A word of caution:

When it comes to interface delegation, reference counting is actually the least
thing to worry about, especially if delegating by class-type property. This
functionality has been just introduced, and it is by no means in stable state.
The most important difference from Delphi is that FPC requires that the delegate
class implements the required interface by itself, while Delphi does not. Actually,
Delphi delegates not the interface but its individual methods (it took me quite a while
simply to realize this fact - and my patches to this part compiler were submitted *before* I
realized it).
The consequences of Delphi design are just ugly: every call to a method of a delegated
interface goes through the interface getter, and if getter is a function, it easily
becomes top #1 in the profiler log.
While current FPC implementation does not have this ugliness, it is Delphi-compatible only to 
certain extent, and may change in the future. So I'd avoid to rush and rely on it in the base classes.

Regards,
Sergei