[fpc-devel] Published record

[Michalis Kamburelis]

Thank you -- this is excellent information, both RTTI for records and
lazarus/components/jitclasses/ . So I really have all the puzzle
pieces I need :)

I have recorded a TODO to handle it all in
https://castle-engine.io/roadmap#records_rtti .

Regards,
Michalis

niedz., 18 sie 2024 o 10:49 Michael Van Canneyt
<michael at freepascal.org> napisał(a):
>
>
>
> On Sat, 17 Aug 2024, Michalis Kamburelis wrote:
>
> > Thanks Michael!
> >
> > OK, that's partially good news :)
> >
> > I understand that streaming records by default to LFM would lead to
> > too many questions (and I'm unsure whether Delphi does it too, for
> > records and DFM).
>
> It does not.
> Streaming has not changed in an essential way since  D7, I think.
>
> With the coming of extended rtti, they could have changed it, but they
> didn't, I believe since it would be difficult to maintain backwards
> compatibility.
>
> > If this means they are not allowed in the
> > "published" section, *but* the RTTI is capable of telling me what
> > records are in the "public" section, and read / write them (using
> > proper getters / setters), this is something we can work with.
>
> You should be fine then, as this is supported.
>
> >
> > I mean, I can 1. add my own serialization / deserialization of them,
> > and 2. make them exposed in the object inspector in CGE editor.
> >
> > (
> > Details:
> > AD 1 - For serialization / deserialization, in Castle Game Engine, we
> > use CastleComponentSerialize on top of FpJsonRtti. One of the reasons
> > I like JSON and FpJsonRtti over LFM is that this gives us more control
> > -- I know I can add code to CastleComponentSerialize to deal with
> > records, if only RTTI tells me about them.
>
> I prefer JSON too.
>
> > AD 2 - For object inspector, we use Lazarus "ObjectInspector" unit.
> > I'm less sure about it, but hopefully it is possible to add there
> > "fake" subcomponents too.
> > )
>
> Actually, it is!
>
> see the work the FP/Lazarus foundation sponsored in
>
> lazarus/components/jitclasses/
>
> >
> > Can you expand your statement "It is since some time, but you must
> > explicitly enable it."? What compiler switch enables it? What API
> > should I use to access it -- Rtti unit in FPC has all we need? (I
> > guess TypeInfo unit API does not expose it, or it does?)
> >
> > To make my question more concrete, imagine a code like this:
> >
> > """
> > type
> >  TVector3 = record X, Y, Z: Single end;
> >  TCastleTransform = class
> >  public
> >    property Translation: TVector3 read ... write ...;
> >    property Scale: TVector3 read ... write ...;
> >  end;
> > """
> >
> > I'm looking for a way to tell, at runtime, using RTTI, having any
> > instance of TObject (maybe of TCastleTransform):
> >
> > - what public properties of type TVector3 are there (like
> > "Translation" and "Scale"),
> > - what public fields does TVector3 have (like X, Y, Z) (this is
> > nice-to-have, we could work without this info but then limiting our
> > record serialization / deserialization to only specific record types),
> > - read / write these record properties using the proper getter /
> > setter (whether it's direct field access or a method).
>
> This is all perfectly possible.
>
> Simply add
>
>    {$RTTI EXPLICIT
>       PROPERTIES([vcPublic])
>       FIELDS([vcPublic])
>       METHODS([vcPublic])}
>
> in your units and you're all set.
>
> Michael.