[fpc-devel] Assigning to inherited property calls setter of the child class

Mattias Gaertner nc-gaertnma at netcologne.de
Fri May 1 16:56:53 CEST 2009


On Sat, 2 May 2009 01:45:14 +1100
Alexander Klenin <klenin at gmail.com> wrote:

> This mail is to discuss issue
> http://bugs.freepascal.org/view.php?id=13630.
> 
> >From the issue description:
> 
> Given the definitions:
> 
> type
>   T1 = class
>     procedure SetP(AP: Integer); virtual;
>     property P: Integer read FP write SetP;
>   end;
> 
>   T2 = class(T1)
>     procedure SetP(AP: Integer); override;
>   end;
> 
> procedure T1.SetP(AP: Integer);
> begin Writeln('T1.SetP'); end;
> 
> procedure T2.SetP(AP: Integer);
> begin Writeln('T2.SetP'); inherited P := AP; end;
> 
> the assignment t2obj.P := 1 causes infinite recursion,
> because "inherited P := AP" calls T2.SetP instead of T1.SetP.
> 
> This problem was already reported, fixed, but the fix was reverted:
> http://bugs.freepascal.org/view.php?id=10927
> http://bugs.freepascal.org/view.php?id=10979
> (sorry for not searching the Mantis myself before posting the issue).
> 
> However, I believe that the problem in issue 10979 was caused by
> incorrect fix to 10927 and it is actually possible (and desirable)
> to fix both.
> 
> inherited P := V
> 
> Should:
> 1) Search base classes to find the definition of P in some class B.
> 2) If it is not writable, error out.
> 3) If it writes to a field, do that.

So far, so good.

> 4) If it has setter named "SetP", do the equivalent of "inherited
> SetP".

Why?

"inherited P" should look up P in the ancestor class. 
The setter of P belongs to the internal implementation of
the class. If you want to access the inherited setter, call it with
inherited SetP.

 
> it is the presence vs. absence "inherited" in step 4 that should have
> been changed
> to fix 10927, but it sounds like a "B.SetP" was used instead, which
> caused issue 10979.
> 
> Regarding Delphi compatibility -- note that current behavior leads to
> stack overflow in both Delphi and FPC, so I doubt there are many
> programs relying on it ;-)

 
Mattias



More information about the fpc-devel mailing list