objc data structures

[Ziemowit Laski]

>>>>> - What is actually being stored in these fields?
>>>>
>>>> For now, just protocol annotations (e.g., 'NSObject <NCCopying, 
>>>> NSArchiving> *').
>>>
>>> So, it's one tree pointer?
>>
>> That's all I need, since I can store them as a TREE_LIST (or some 
>> other structure if need be).
>
> OK.  If you could have whatever data structure you wanted, would it 
> still be a tree pointer?

Hmm... TREE_LISTs are quite sufficient for this task, but we could also 
use a different data structure if you think that would make more sense.
>
>>>>> - How often is it used?
>>>>
>>>> Very often.  Protocols are used very heavily in AppKit and 
>>>> Foundation, for example.
>>>
>>> No, I mean "how often is it used in a compilation".  As in, is it 
>>> used every time a field is referenced?
>>
>> Protocols attach to types, not fields.  Protocols are used in type 
>> comparisons and when dispatching ObjC messages (so that the proper 
>> method signature may be selected), but are not needed for things such 
>> as codegen.
>
> OK.  So the data would be used each time a type is compared or when an 
> objc message is dispatched to an object.

Yes.

>
>>>>> - Is it ever necessary to have this information as well as the 
>>>>> information that C or C++ stores in the lang_specific field?
>>>>
>>>> No idea.
>>>
>>> Could you please find out?  This information is essential to the 
>>> design.
>>
>> How do you suggest I do that?  You're asking me to establish 
>> constraints on the use of a local data structure by other front-ends.
>
> Is it necessary in the current compilers, to which you have source?

Even if the "current compilers" were set in stone, I still fail to see 
how you'd compute this predicate.

> More generally, given what the current compilers have in the lang_type 
> structures, is it necessary to have both that data and the data that 
> objc needs?
>
> Or, to phrase it another way, could we just decide that lang_type can 
> be a union that can point to either the data that objc needs or the 
> data that the C or C++ frontend needs?

You're asking me
   (1) the exact conditions under which C or C++ might decide to store 
lang_specific information in a type node; and
   (2) the exact conditions under which ObjC/ObjC++ needs to store 
lang_specific information (for now, protocols) in a type node; and
   (3) whether (1) and (2) are guaranteed to be mutually exclusive.

The only one of these I could even _begin_ to answer is (2).  Unless 
you can present a methodology for computing (1), as well as ensuring 
that _no_ future patch to the C or C++ front-ends alters (1) in ways 
that violates (3), I posit that the C/C++ and ObjC/ObjC++ lang_specific 
information must be treated as orthogonal.

--Zem