[fpc-devel] Published record

[Michael Van Canneyt]

On Sat, 17 Aug 2024, Kostas Michalopoulos via fpc-devel wrote:

> On 8/16/24 8:40 PM, Michalis Kamburelis via fpc-devel wrote:
>> If we could instead just put TVector3 in the published section, and
>> make it exposed in the object inspector (maybe adding some additional
>> code to use RTTI, but that is made *once*, not every time we need to
>> expose TVector3) this would be great :)
>
> Seconding this, for pretty much the same use case: my 3D game engine also 
> uses TVector, etc records (and objects! - stuff being allocated in stack or 
> "inline" other objects/classes is incredibly important) and needs to expose 
> them via RTTI/published and i have to use various kludgy hacks to work around 
> a language limitation that IMO was already questionable back in the 90s when 
> Delphi 2 was released (i might kinda accept it for Delphi 1 having to work in 
> 16bit mode :-P).
>
> Instead of having a proxy object, i "flatten" the fields using getters and 
> setters so, e.g., a "property Position: TVector read FPosition write 
> SetPosition" in the public section also has "property PositionX: Single read 
> GetPositionX write SetPositionX" and similar for PositionY and PositionZ. 
> Obviously with something like "property Transformation: TTransformation read 
> FTransformation write SetTransformation" which has Position, Rotation and 
> Scale properties (as TVectors) that get flattened to nine published 
> properties so they can be accessed via RTTI (and thus have automatic 
> serialization, deserialization, property editing UI, clipboard copy/paste, 
> undo/redo support via property diffs, etc without having to do all that 
> manually via code) it becomes kinda unwieldy fast.
>
> Sadly i also do have to use proxy objects in some cases, e.g. i have a 
> generic object "TDynArray" for dynamic arrays which is wrapped via a 
> "TSerializableCollection" class so that the serialization/deserialization 
> code can automatically write/construct/read published collections of objects.
>
> It'd be very useful if the Run-Time Type Information could describe all the 
> Type Information the compiler already knows about :-P

See my answer to Michalis: It is possible, but no streaming, so no published.

Michael.