[fpc-devel] class-attributes

[Sven Barth]

On 24.05.2012 20:07, Joost van der Sluis wrote:
> On Thu, 2012-05-24 at 18:48 +0200, Sven Barth wrote:
>> On 24.05.2012 15:27, Joost van der Sluis wrote:
>>> On 17 May 2012, at 23:32, Joost van der Sluis wrote:
>>> I could, but I attached a patch first. Before I commit this to a branch
>>> I want to know that I'm on the right track. Could you and/or others have
>>> a look at the patch?
>
>> * please call your "generate_rttiattribute_procs" after the
>> "generate_specialization_procs" as methods of generics could force the
>> specialization of a class that is not yet specialized, but that carries
>> attributes
>
> Ok, I'll change that.
>

Thanks.

>> * maybe it's better not to generate attribute data for generics, I don't
>> know... (simply check for "df_generic in ttypesym(p).typedef.defoptions"
>> in generate_rttiattribute_procs_classes)
>
> I'll will look what Delphi does. In principle i don't a reason why it
> shouldn't work.
>

I don't know whether you can query the RTTI of a generic class at all 
(note: I talk about the generic itself, not a specialization of it); 
also the RTTI generation in FPC is already disabled for generics (as 
well as the VMT generation).

>> * in generate_rttiattribute_procs_properties you also need to handle
>> nested classes
>
> Ah yes, offcourse. I will also look at the 'normal' rtti generation, I
> copied the code from there. Maybe that there is no rtti information
> generated for nested classes at all at this moment.
>

If so this should be fixed AFAIK.

>> * you might want to call me blind, but where did you add the field
>> rtti_attributesdef to, to which you assign the current_rttiattributedef?
>> (can it be that you forgot that in the patch?)
>
> See the second change in pdecobj. (In procedure truct_property_dec)
>

Yes, I see the change in pdecobj, but I'm missing the change in the 
class where "p" is an instance of. Ah... now I found what I was looking 
for: the change in symsym.pas... ^^

>> And two questions:
>> * does the usage of attributes with methods/fields depend on the
>> availability of the extended RTTI?
>
> Yes. Without extended RTTI you can not get a list of method/fields at
> runtime. So where should the attributes be bound to?
>

Ok... then it's indeed better to wait with attributes for other class 
members besides properties until the extended RTTI is added as well.

>> * can attributes also be used with records in Delphi? (as they can now
>> carry properties as well)
>
> I don't know. Do we support rtti on records? I think this is also a part
> of what Delphi calls 'extended rtti'.

I don't know either. I just wanted to ask out of completeness ^^

Otherwise from the perspective of a "junior compiler developer" the 
patch looks ok. :) [I haven't tested it yet though]

Regards,
Sven