Am 02.03.2016 20:02 schrieb "Maciej Izak" <[email protected]>: > > 2016-03-02 19:30 GMT+01:00 Sven Barth <[email protected]>: >> >> 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
_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
