[fpc-devel] Improved RTTI compromise

[Sven Barth]

On 06.12.2016 23:27, Maciej Izak wrote:
> 2016-12-06 22:49 GMT+01:00 Sven Barth <pascaldragon at googlemail.com
> <mailto:pascaldragon at googlemail.com>>:
> 
>     We won't need Invoke() function for attributes, since Joost's branch
>     generates a function that calls the attribute class' constructor with
>     the provided values and returns the created instance.
>     This has the advantage that it's a) faster and b) works on all supported
>     platforms whereas Invoke() will not be supported on all platforms at the
>     beginning and additionally requires the parameter RTTI to be in place
>     (basically what's introduced with the Interface RTTI branch).
> 
> 
> Yes I really like all of mentioned advantages!... at the beginning I was
> a little confused how it works without Invoke in RTTI.pas. Indeed good
> idea, but if we really like to have Delphi clone of attributes (with
> logic and typinfo data) then Invoke is needed.

Most Delphi code probably uses the RTTI unit anyway for this. And when
playing with the RTTI one needs to keep track of FPC vs. Delphi anyway
cause we'll never be 100% compatible (e.g. the Interface RTTI branch
does not keep in mind parameters that might be split across multiple
locations (like two registers), so that needs to be extended compared to
Delphi).
However I think that we'll add the Delphi compatible TAttrEntry, but
with an additonal AttrCreate field before the AttrCtor field. The former
will then contain a pointer to the generated "fast invoke" function
while AttrCtor, ArgLen and ArgData will be Delphi compatible.

>     I've just looked through Joost's branch. One of the biggest problems is
>     the unit list and the list of types contained in each unit. Since this
>     is only introduced in the branch and the introduction of dynamic
>     packages completely shakes that up (I want to be able to look up types
>     of packages that were dynamically loaded after all ;) ).
>     So if we agree that for now TRttiContext either is removed or its
>     methods return Nil and attribute support is also removed for now then we
>     can indeed move the RTTI unit rather unceremoniously to trunk (I'll need
>     to rework Joost's branch anyway).
>     Since we now also support generic functions we can also add the missing
>     functions of TValue ;) (patches welcome once we've indeed merged it)
> 
> 
> Sure, very welcome. TValue is good for beginning (would be cool to use
> TValue with MO). RTTI.pas might be good start point for early
> implementation of "Invoke" for few platforms.

Okay then, maybe I'll manage that this week (no promise though ;) ).
I personally think that removing TRttiContext for now is the better
choice, so people will know not to use it while they might expect valid
values in the other case...

I don't know whether an early implementation of Invoke() would be a good
idea already as it would need a heavy rewrite once parameter location
support is available in the RTTI...

Regards,
Sven