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 <mich...@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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
