objc data structures

[Geoffrey Keating <geoffk at apple dot com>]

On 07/10/2004, at 11:08 AM, Ziemowit Laski wrote:

> On 7 Oct 2004, at 9.47, Geoffrey Keating wrote:
>
> > On 06/10/2004, at 5:35 PM, Ziemowit Laski wrote:
> >
> > > On 6 Oct 2004, at 17.15, Geoffrey Keating wrote:
> > >
> > > > On 06/10/2004, at 4:51 PM, Ziemowit Laski wrote:
> > > >
> > > > > On 6 Oct 2004, at 16.18, Geoffrey Keating wrote:
> > > > >
> > > > > > Hi Zem,
> > > > > >
> > > > > > How's the objc++ merge doing?
> > > > >
> > > > > You're blocking it:
> > > > >
> > > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02513.html
> > > >
> > > > Aaah, yes.
> > > >
> > > > So, I need some more information from you.
> > > >
> > > > - 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?

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

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

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?

If we did that, I guess we'll need to still have the data that the C 
frontend has, the sorted list of fields, so actually it'll be a 
slightly complicated structure.  Would we still need the data that the 
C++ frontend can have for records ("classes")?

> > >   However, even if we were to somehow convince ourselves that both 
> > > C/C++ and ObjC lang_specific info is needed
> > > simultaneously _today_, this might not hold true in the future as 
> > > more C/C++ lang_specific stuff gets added.
> >
> > At that point, we would need to reconsider this design.  However, 
> > there is no benefit in penalising today's compiler because of 
> > something that might or might not happen in the future.
>
> Don't know what you mean by "this design", since we don't have one yet.

The design that we're making.

> At any rate, please take this discussion to gcc-patches where it 
> belongs.

Sure, except that the right mailing list is gcc-devel, since there is 
no patch here.

--
Geoff Keating <geoffk@apple.com>

Attachment: smime.p7s
Description: S/MIME cryptographic signature