[fpc-devel] Differences between 'tsym' and 'tdef'

[Joost van der Sluis]

On Fri, 2012-05-18 at 15:13 +0800, Paul Ishenin wrote:
> 18.05.2012 14:23, Joost van der Sluis wrote:
> 
> > This information can be bound to a properties but also whole classes at
> > least. (I'll have to test for methods and public fields) So no, not only
> > properties may have this information.
> 
> If methods may have this information then it is not possible to put it 
> to tsym because paticular method is a tprocdef and several tprocdefs may 
> have 1 tprocsym (overloaded methods). Therefore I would put this info to 
> tstoreddef. But what to do with a property? Create a special def for it?
> 
> > And, to answer your second question, properties in a descendant class do
> > *not* inherited the properties of the ancestor. I found that pretty
> > strange, but that's how it is implemented in Delphi.
> 
> There may be 3 cases. Does it work in any:
> 
> case 1: property descendant
> 
> TAncestor = class
>    [attributes]
>    property SomeProp: TSomeType read GetSomeProp;
> end;
> 
> TDescendant = class(TAncestor)
>    property SomeProp write SetSomeProp; // <- this is property descendant
> end;

This one should not have any attributes.

> case 2: new property hides old
> 
> TDescendant = class(TAncestor)
>    property SomeProp: TSomeType read GetSomeProp; // <- this property 
> hides old SomeProp
> end;

Also not.

> case 3: new class uses property as is
> 
> TDescendant = class(TAncestor)
> end;

Also not. (I know, it is strange behavior. But there are more strange
things, as there is no type-checking in attributes. It seems like they
just hacked this together rather quickly...) 

> > So in this case create a special symbol and symtable for it?
> 
> Looking at 
> http://docwiki.embarcadero.com/RADStudio/en/Annotating_Types_and_Type_Members 
> I see that attribute is a class + a list of arguments for that class 
> contructor. As this is a class - compiler already creates a symbol and a 
> definition for it and all it members. So you need to store a link to 
> this class (or to class contructor) + a list of arguments to pass there. 
> So it is not a special symbol, just a reference to it. If you need an 
> example of how to store/restore reference to a class then look at how it 
> is done with tobjectdef.childof or tobjectdef.extendeddef.

Indeed. And I do have the symbol of the corresponding type and a list of
parameters already. I thought I needed a symbol/definition to store the
references. Else I would have to store those references in the
TPropertySym, but also in the symbol of the class. That doesn't look
good to me?

Joost.