<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2017-01-31 19:35 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="m_-7932926851936935249gmail-m_928456060822378744:59q" class="m_-7932926851936935249gmail-m_928456060822378744a3s m_-7932926851936935249gmail-m_928456060822378744aXjCH m_-7932926851936935249gmail-m_928456060822378744m159f5cfe50f042a6">A little sidenote: the "day unique" part of an internal error is<br>
supposed to be two digits and to start from 1, so your internal error<br>
should have been <a href="tel:2017011801" value="+12017011801" target="_blank">2017011801</a> instead of 201701180 (I've corrected that<br>
already).</div></blockquote><div><br></div><div>Ok. Another sidenote to remember. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-7932926851936935249gmail-m_928456060822378744:59q" class="m_-7932926851936935249gmail-m_928456060822378744a3s m_-7932926851936935249gmail-m_928456060822378744aXjCH m_-7932926851936935249gmail-m_928456060822378744m159f5cfe50f042a6">I still can't recommend the way it's done in mORMot. This will break<br>
each time the binary format of the RTTI changes. Take my adjustment of<br>
TProcedureParam.Flags (now .ParamFlags) for example which I changed from<br>
Byte to TParamFlags which not much later changed its size from Byte to<br>
Word due to newly added elements. You might not catch such a change<br>
especially if it should be used in a seldomly used code branch.<br></div></blockquote><div><br></div><div>...and that is why we have NewPascal also as "buffer". When someone is using NewPascal instead of pure FPC trunk, can be sure that he has right version of FPC trunk for mORMot. My every day starts from checking what is new in ncgrtti and typinfo :) so don't worry. Anyway I am just human, so maybe more detailed test suite for RTTI binary consistency is good idea. Whatever we discuss here I can't make such decision. IMO only main author of mORMot (Arnaud Bouchez) has rights for such important changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-7932926851936935249gmail-m_928456060822378744:59q" class="m_-7932926851936935249gmail-m_928456060822378744a3s m_-7932926851936935249gmail-m_928456060822378744aXjCH m_-7932926851936935249gmail-m_928456060822378744m159f5cfe50f042a6">
My suggestion would be an RTTI abstraction that makes use of inline<br>
methods/properties  as part of objects/records to access the Delphi and<br>
FPC RTTI.<br></div></blockquote><div><br></div><div>And we have that abstraction too (!)... The most painfully part is collecting the data in optimal way (also part of data lands into cache) and we need to keep single code base as possible with many versions of Delphi which is not trivial task.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-7932926851936935249gmail-m_928456060822378744:59q" class="m_-7932926851936935249gmail-m_928456060822378744a3s m_-7932926851936935249gmail-m_928456060822378744aXjCH m_-7932926851936935249gmail-m_928456060822378744m159f5cfe50f042a6">
For example another change that will come up in the near future will be<br>
a link from the TTypeData to the unit its contained in which will again<br>
lead to a shift in fields.</div></blockquote></div><div class="gmail_extra"><br></div>We have a lot of "breaking changes" behind us. We will take the challenge. ;)<br clear="all"><div><br></div>-- <br><div class="m_-7932926851936935249gmail-m_928456060822378744gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>