[fpc-devel] Patch #31249 and objects

[Maciej Izak]

2017-01-31 19:35 GMT+01:00 Sven Barth <pascaldragon at googlemail.com>:

> A little sidenote: the "day unique" part of an internal error is
> supposed to be two digits and to start from 1, so your internal error
> should have been 2017011801 instead of 201701180 (I've corrected that
> already).
>

Ok. Another sidenote to remember. :)


> I still can't recommend the way it's done in mORMot. This will break
> each time the binary format of the RTTI changes. Take my adjustment of
> TProcedureParam.Flags (now .ParamFlags) for example which I changed from
> Byte to TParamFlags which not much later changed its size from Byte to
> Word due to newly added elements. You might not catch such a change
> especially if it should be used in a seldomly used code branch.
>

...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.


> My suggestion would be an RTTI abstraction that makes use of inline
> methods/properties  as part of objects/records to access the Delphi and
> FPC RTTI.
>

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.


> For example another change that will come up in the near future will be
> a link from the TTypeData to the unit its contained in which will again
> lead to a shift in fields.
>

We have a lot of "breaking changes" behind us. We will take the challenge.
;)

-- 
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170131/1c750628/attachment.html>