[fpc-devel] Allow record helper inheritance in Delphi mode
Stefan Glienke
sglienke at dsharp.org
Fri Sep 1 11:41:59 CEST 2017
Again you will cause unnecessary headaches because now your helper has the dependency of the builtin and the third party one.
How would third party one and third party two implement them? They both probably would extend the builtin one. Which one can you use in your code then?
Yes, the one that comes last in the uses. What if you want to use functions from both? Out of luck again.
Inheritance regardless what form is never is the best option here. I think "ancestor list" is just a misnomer in the documentation as it cannot be a list but only one in case of class helper.
> On 01 September 2017 at 09:40 Ondrej Pokorny <lazarus at kluug.net> wrote:
>
>
> On 01.09.2017 8:47, Stefan Glienke wrote:
> > Inheritance seems like the obvious way but you just defer the "I
> > cannot extend the builtin helpers" problem.
> > If any third party code decides to do so you are at the same point
> > again because now do you inherit from the third party helper or from
> > the builtin one?
> > What if two third parties inherit from the helper?
>
> Yes, you are right, I forgot about this issue.
>
> > Therefor I argue that the "only the last one in scope is applied"
> > restriction should be removed.
>
> This could be also solved by supporting "ancestor list" (what Delphi
> documentation talks about but the compiler doesn't allow it again):
>
> TEmbarcaderoHelper = class helper for TObject
> public
> end;
>
> TThirdPartyHelper = class helper for TObject
> public
> end;
>
> TMyHelper = class helper(TEmbarcaderoHelper, TThirdPartyHelper) for
> TObject
> public
> end;
>
>
> Ondrej
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
More information about the fpc-devel
mailing list