[fpc-devel] Allow record helper inheritance in Delphi mode

[Stefan Glienke]

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?

Therefor I argue that the "only the last one in scope is applied" restriction should be removed.
If there are any clashes because two helpers introduce a any ambiguity well then it is the compilers job to warn or error about those and provide a way to explicitly call the method from one specific helper by hardcasting the instance to the helper type or otherwise.

> On 31 August 2017 at 17:47 Ondrej Pokorny <lazarus at kluug.net> wrote:
>
>
> On 31.08.2017 17:22, Sven Barth via fpc-devel wrote:
> > > I remember a compiler bug in class destructor order call in Delphi:
> > https://stackoverflow.com/questions/19332847/delphi-class-variable-going-out-of-scope-before-class-destructor-is-called
> >
> >
> > That should get solved once I reworked the unit initialization which
> > is the last real blocker for dynamically loading packages.
> >
>
> What I particularly like is that you considered it as a bug and were
> open for a discussion from the very beginning - even if the behavior was
> Delphi compatible at that point. Not like Embarcadero closing eyes and
> ears until they really had to solve it. All kudos to you and the FPC team :)
>
> Maybe Embarcadero changes their record inheritance policy as well at
> some point - especially because they introduced record helpers for
> primitive types (like TStringHelper). Not having inheritance for them
> forbids easy extension of them.
>
> Ondrej
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel