<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-12-10 0:54 GMT+01:00 Sven Barth <span dir="ltr"><<a href="mailto:pascaldragon@googlemail.com" target="_blank">pascaldragon@googlemail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:5rp" class="gmail-a3s gmail-aXjCH gmail-m158e60274583c98f">We rename ManagedFldCount to TotalFieldCount, add a field<br>
ManagedFieldCount and a property ManagedFldCount that returns<br>
TotalFieldCount for backwards compatibility (and maybe marked as<br>
deprecated).<br></div></blockquote></div><br>I've created new bug report to express my strong stand about this problem:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://bugs.freepascal.org/view.php?id=31102">http://bugs.freepascal.org/view.php?id=31102</a><br></div><div class="gmail_extra">(copied from bug report)</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">FPC has long standing critical issue. ManagedFldCount field in TypInfo (TTypeData) contains "count" for all fields (but should contains "count" for managed fields only - as name suggest). It is not feature but highly visible bug.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* The bug has critical meaning for development of RTTI.pas because is impossible to implement in rational way IsManaged function (ManagedFldCount is used for that) </div><div class="gmail_extra">* The bug has many performance issues  especially for InitializeArray/FinalizeArray.</div><div class="gmail_extra">* The bug means more Delphi incompatibility RTTI.</div><div class="gmail_extra">* For scripting languages it means many troubles (for Delphi porting code)</div><div class="gmail_extra">* TManagedField entry for each (I mean here unmanaged fields) field has zero value for programmer, it has no sense.</div><div class="gmail_extra"><br></div><div class="gmail_extra">any partial fix with pseudo backward compatibility has no sens and will bring much more noise and confusion  and more complicated RTTI code without real gain.</div><div class="gmail_extra"><br></div><div class="gmail_extra">the proper layout for part related to records (in current state) in TTypeData is:</div><div class="gmail_extra"><br></div><div class="gmail_extra">      tkRecord: ( // could be extended for info about attributes, methods and operators (maybe also properties)</div><div class="gmail_extra">        RecSize: Integer;</div><div class="gmail_extra">        ManagedFldCount: Integer;</div><div class="gmail_extra">       {ManagedFields: array[0..ManagedFldCnt - 1] of TManagedField;</div><div class="gmail_extra">        RecFldCnt: Integer;</div><div class="gmail_extra">        RecFields: array[1..RecFldCnt] of TRecordTypeField});</div><div class="gmail_extra"><br></div><div class="gmail_extra">where </div><div class="gmail_extra"><br></div><div class="gmail_extra">  TRecordTypeField = packed record</div><div class="gmail_extra">    Field: TManagedField;</div><div class="gmail_extra">    Flags: Byte; // visibility</div><div class="gmail_extra">    Name: ShortString;</div><div class="gmail_extra">  end;</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">When we have additional "Name" and "Flag" for managed and unamanaged fields it has sense, because when we have more info than pure TManagedField for each field, it could be used for ORM or for scripts. Probably is good idea to correlate RecFields together with:</div><div class="gmail_extra"><br></div><div class="gmail_extra">{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}</div><div class="gmail_extra"><br></div><div class="gmail_extra">The patch provided in #29767 is wrong when we thinking about extended RTTI (init table should stay simple as possible), same for MO PART 2 ( <a href="http://bugs.freepascal.org/view.php?id=30687#c96093">http://bugs.freepascal.org/view.php?id=30687#c96093</a> )</div><div class="gmail_extra"><br></div>It must be changed same as was needed change for indirect type info (PPTypeInfo) for greater good.<br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>