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

Sven Barth pascaldragon at googlemail.com
Thu Aug 31 17:22:49 CEST 2017


Am 31.08.2017 15:55 schrieb "Ondrej Pokorny" <lazarus at kluug.net>:
>
> On 31.08.2017 14:55, Sven Barth via fpc-devel wrote:
>>
>>
>> > Yeah, they might enable record helper inheritance for example :P
(Record helper inheritance was documented to work for about 7 years since
Delphi 2007 until XE6
http://docwiki.embarcadero.com/RADStudio/XE6/en/Class_and_Record_Helpers_(Delphi)
<
http://docwiki.embarcadero.com/RADStudio/XE6/en/Class_and_Record_Helpers_%28Delphi%29>
).
>>
>> >
>>
>> Huh? I had developed the feature while testing with Delphi XE and there
record helpers did not support inheritance, only class helpers did. So as
long as you don't provide prove I'd say that this is a documentation bug.
>>
>
> That's exactly what I say: record helpers don't support inheritance but
the documentation (until XE6) says nothing about this restriction, on the
contrary. Only in XE7 they added the "It [the ancestor list] can be
specified only for class helper." line. See:
>
>
http://docwiki.embarcadero.com/RADStudio/XE6/en/Class_and_Record_Helpers_(Delphi)
>
http://docwiki.embarcadero.com/RADStudio/XE7/en/Class_and_Record_Helpers_(Delphi)
>
> It is a matter of point of view if it was a documentation bug or a
compiler bug. Embarcadero shared your opinion with "documentation bug". (My
personal opinion is that they just forgot about inheritance when they
implemented record helpers and then instead of fixing the compiler they
fixed the docs - yeah because it's easier.)

No, I don't think they thought this way. Class and record helpers weren't
largely advertised back when they were introduced. They even had the note
that one shouldn't use them for own implementations. And for record helpers
they modelled them after records. If I remember correctly the "protected"
section isn't allowed in record helpers either, because it isn't allowed in
records.

> +++++
>
> 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
>
> There were several issue reports about it in Embarcadero Quality Central
(which is now down, so I can't provide the links), all resolved as "won't
fix". Embarcadero always claimed this was by design.
>
> But when they introduced ARC they suddendly couldn't justify the design
flaw because consequently class objects were not available in class
destructors in ARC mode but they were available in non-ARC mode. So they
decided to fix the order just like lots of people requested from the very
beginning. IMO it was VERY embarrassing for Embarcadero.
>
> By the way, FPC is affected by the very same bug:
https://mantis.freepascal.org/view.php?id=29334 .
>

That should get solved once I reworked the unit initialization which is the
last real blocker for dynamically loading packages.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170831/53ec0692/attachment.html>


More information about the fpc-devel mailing list