<div dir="ltr">Hi,<div><br></div><div>I was thinking about extended RTTI, and important RTTI.pas module (good start point with attributes is waiting 3 years). Seems that the only real reason why we don't have yet RTTI.pas in trunk is incompatibility of generated type info (as Jonas said: TAttributeData vs TAttrData, no TAttrEntry).</div><div><br></div><div>Current situation seems like big lock for many developers and development. I see 3 solutions:</div><div><br></div><div>1. TAttributeData with additional compiler hinting directive "experimental"</div><div>2. Moving TAttributeData into implementation section (and related functions accessible through alias&special *.inc for RTTI.pas). Only usage of attributes through RTTI.pas would be allowed.<br><div>3. Not merged.</div><div><br></div><div>Point 1&2 is fair enough (especially 1). We can change RTTI layout in the future (when Invoke will be implemented). I think that speed of development of RTTI.pas will increase (btw. management operators are perfect for TValue).</div><div><br></div><div>For point 3 I am forced to add RTTI branch into NewPascal project which is dangerous for both projects and for me personally. Today I need to read ridiculous messages (for example from Blaise in "Closures / anonymous methods" topic) about "no respect" for my person ^^ because I have Open Source supporting project (as Blaise said: I am <span style="font-size:12.8px">schismatic which create unnecessary forks, splitting the community and resources).</span> For me NP is start point for many patches merged back into FPC, libraries and motivation for improvements and for discussions with core team about improvements. *Sooner or later someone will send agent 47 to eliminate me ;) so please rethink decision about RTTI branch*.</div><div><br></div><div>Maybe RTTI branch has some hidden flaw?</div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>