Re: objc data structures

[Ziemowit Laski <zlaski at apple dot com>]

> > > > > - 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