[fpc-devel] Twice stored record RTTI data

Sven Barth pascaldragon at googlemail.com
Wed Mar 2 23:38:09 CET 2016


Am 02.03.2016 20:02 schrieb "Maciej Izak" <hnb.code at gmail.com>:
>
> 2016-03-02 19:30 GMT+01:00 Sven Barth <pascaldragon at googlemail.com>:
>>
>> I can already tell you now that this part of your code will definitely
not be merged then.
>
> ok. no problem with that, I got used to, similar like many other Delphi
compatible code - for example Generics.Collections. ;)

With your collection it's more that I feel uneasy with your implementation.
In general I'm in favor of the addition... But this topic is definitely
different.

>>
>> It will break code that relies on non-managed fields being present in
the RTTI. As Jonas said our RTTI is not guaranteed to be Delphi compatible,
so *introducing* Delphi compatibility while *sacrificing* backwards
compatibility (namely to enumerate non-managed fields) is *not* acceptable.
>
>
> Who is using non-managed fields from array that presents managed fields?
Srsly? Proper code will not work with current implementation. It can be
different in *details*, but it should be *functional similar* to Delphi -
in this case it is not.
>
> The usage of this FPC part is marginal so patch probably don't break
anything, and even more - it provide better Delphi compatibility on
"functional" level.
>
> FPC is holding non-managed fields in array for managed fields - terrible.
Nothing more to say.

How can you know that no one is using this? And only because it's called
ManagedFields (or so) that doesn't mean that users haven't discovered that
it contains all fields and use it as such.
Also any valid code should work with the additional fields as well since it
will have to check the type kinds anyway.
Changing this would break *any* code that relies on the fields being in
there, while only that code that does an Assert(False) or something alike
will fail with the additional ones.
So again: we won't change this.

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


More information about the fpc-devel mailing list