<p>Am 12.04.2016 14:58 schrieb "Maciej Izak" <<a href="mailto:hnb.code@gmail.com">hnb.code@gmail.com</a>>:<br>
>><br>
>> > Note: these attributes are on my TODO list.<br>
>><br>
>> Please don't do anything attribute related until I've merged Joost's class attributes branch which lays the foundations for the attributes. I've planned this for after the reintegration of my dynamic packages branch which is currently WIP (the merge, not the branch ;) )<br>
><br>
> IIRC the branch is incomplete (for example RTTI in early stage and for example TValue need to be improved). Extending these branch is also on my TODO. :) Maybe the only target of mentioned branch is to allow attributes of classes (which has no much sense without Invoke method and extended RTTI - and that is absolutely unimplemented).</p>
<p>Attributes are implemented differentlybin FPC than in Delphi. In FPC a constructor routine is created which calls the attribute class' constructor. This in turn is what's provided in the RTTI (don't know whether the parameters are currently provided as well, but they shouldn't be needed anyway with that approach). This has the added benefit that attributes don't need a working Invoke() implementation on each and every platform (which is an important point for a cross platform compiler like FPC).<br>
Also I'm aware that the branch currently only allows class attributes, but that should be the least problematic part to extend.<br>
So just let me reintegrate the code and we can work from there.</p>
<p>>> That together with your suggestion to force this attribute for records with management operators might indeed be useful, but there are some problems... (see below)<br>
>><br>
>> > ...<br>
>><br>
>> The system unit's initialization *must* be run first, otherwise you won't have a heap or synchronisation primitives or whatever you might need. That then also extends to units like heaptrc, cmem, cthreads, etc.<br>
>><br>
>> Maybe it would be better to initialize such records always *after* *all* initialization sections have been run... :/ (and deinitialized first)<br>
><br>
> Maybe "run" for my idea is a bad word. We don't need to run any section before initialization section from system. What we need is the table/list with "fixed" variables which needs to be initialized in system.pp initialization (and finalized in finalization). I think that is doable.</p>
<p>It doesn't matter. You need to run the initializer operators and these might rely on functionality that is not initialized yet. So the safest approach would definitely be to init these after all initialization sections and to document this and the reasons behind it. This also alleviates the need to use attributes for this (or a keyword or whatever).</p>
<p>Regards,<br>
Sven</p>