<p>Am 07.12.2016 11:31 schrieb "Maciej Izak" <<a href="mailto:hnb.code@gmail.com">hnb.code@gmail.com</a>>:<br>
><br>
> 2016-12-06 23:39 GMT+01:00 Sven Barth <<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>>:<br>
>><br>
>> Most Delphi code probably uses the RTTI unit anyway for this. And when<br>
>> playing with the RTTI one needs to keep track of FPC vs. Delphi anyway<br>
>> cause we'll never be 100% compatible (e.g. the Interface RTTI branch<br>
>> does not keep in mind parameters that might be split across multiple<br>
>> locations (like two registers), so that needs to be extended compared to<br>
>> Delphi).<br>
><br>
><br>
> 100% agree I don't have problem with a little Delphi incompatible RTTI, the bigger picture is more important than small details, but quote from Jonas Maebe ([fpc-devel] Attributes<br>
>  thread): "some people wanted it to be Delphi compatible, other people did not mind if it was not. Both categories of people were in the core team."</p>
<p>I personally am among those who don't need Delphi compatibility ;)</p>
<p>>><br>
>> However I think that we'll add the Delphi compatible TAttrEntry, but<br>
>> with an additonal AttrCreate field before the AttrCtor field. The former<br>
>> will then contain a pointer to the generated "fast invoke" function<br>
>> while AttrCtor, ArgLen and ArgData will be Delphi compatible.<br>
><br>
><br>
> mostly redundant info, but probably best what we can get.</p>
<p>For now we could leave out the AttrCtor, ArgLen and ArgData fields and only add them if someone really needs them...</p>
<p>>><br>
>> I don't know whether an early implementation of Invoke() would be a good<br>
>> idea already as it would need a heavy rewrite once parameter location<br>
>> support is available in the RTTI...<br>
><br>
><br>
> what you mean by "heavy rewrite once parameter location"? Invoke is extremely usefully even without detailed RTTI info about parameters, for example for scripting purposes. I don't mean only pascal functions, script is able to call external system API. Very handy.</p>
<p>Just checked the declaration of Invoke() and my statement was based on a wrong memory of mine as I had forgotten that it merely takes the calling convention and not the parameter locations. Though it might he necessary to add an Invoke() overload that also takes the parameter locations as this way we'd be able to use Invoke() also with the Amiga syscall functions as there the registers to use are specified as part of the functions declaration.<br>
But aside from that you could indeed already start to implement Invoke(), maybe based on the mORMot code.</p>
<p>Regards,<br>
Sven</p>