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

Michael Van Canneyt michael at freepascal.org
Thu May 20 11:45:27 CEST 2010

On Thu, 20 May 2010, Florian Klaempfl wrote:

> michael.vancanneyt at wisa.be schrieb:
>> I need a solution that works with current GUI, current libraries and
>> whatnot. What you propose is re-doing the work of 10 years, which is
>> obviously not feasable.
> Can you give a real world example what you want to do with it?

Like I said, observe TMemo.Strings for changes. Or TObjectList:
additions/removal of objects, so I can update a listview that represents
the objects in the list.

Note that these classes already have extremely simple notification mechanisms; 
It is an enhancement of the existing mechanism. the TFPList class for
instance will not get the notification, as it's purpose is raw speed,
and a clear should not trigger OnChange for every removed object.

> I've no opinion if it's usefull to add or not, I use TPersistent+ too
> little but my concern is: if I create an observer for an instance, I'd
> expect to get notified about every change to the instance. But I cannot
> see how this will be achieved, no existing class is prepared for this?

Not every change. What you get notified about is defined by the class
that uses the observable interface. TStrings will notify you of 
additions/removals, and TList/TObjectList as well. TFPList will not.
This should (and will) be documented.

One can discuss for instance whether setting TComponent.Name should trigger
the change. To my taste, it should not, since normally one doesn't change
the name during the lifetime of a TComponent.

> Shouldn't be ReferenceInterface simply extended with new operations?

I don't think so, for 3 reasons:

1. It works on TComponent only. The solution is needed at TPersistent level.
   (TStrings/TCollection descend from TPersistent).
2. It is a COM interface, which introduces a lot of overhead.
    (init/finalization and the whole reference counting mess)
    My implementation uses CORBA interfaces to avoid that.
3. It would definitely break Delphi compatibility,
    as ReferenceInterface is a Delphi-defined interface :/
    (Maybe it is even a .NET one, but I don't know that)


More information about the fpc-devel mailing list