Re: C++ nested classes, namespaces, structs, and compound statements

[Jim Blandy <jimb at redhat dot com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Wed, Apr 10, 2002 at 12:31:27PM -0500, Jim Blandy wrote:
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > Sure.  But I think this is a chance (if we want one) to move in a
> > > different direction.  We'd have to work out the details, but I envision
> > > something like this (names made up as I go along):
> > > 
> > > struct environment_entry {
> > >   const char *name;
> > >   enum name_type kind;
> > >   void *data;
> > > }
> > > 
> > > enum name_type {
> > >   type_kind,
> > >   field_kind,
> > >   symbol_kind,
> > >   namespace_kind,
> > > };
> > 
> > In other words, replace the sloppy union with a properly discriminated
> > union?  I'm for it.
> > 
> > But granted that it's important to clearly distinguish between the
> > expanding set of uses we're putting `struct symbol' to, and that
> > extending enum address_class isn't the best idea, how is it better to
> > make this change concurrently with the enclosing environment changes?
> > We could do this change right now.  Isn't it basically independent?
> 
> Well, no.  I was suggesting this for things that are not currently in
> symbols (well, types generally are...).  But namespaces are not
> represented at all and fields are in a different structure entirely.

Okay, I think I see.  You're preserving the distinctions implicit in
the existing structures (fields and symbols are separate),
distinguishing types from symbols (i.e. an entry for a typedef would
be an environment_entry whose kind == type_kind, instead of a symbol
with an address class of LOC_TYPEDEF), and positing that namespaces
would be a fourth kind of thing.  The `data' field would point to a
`struct type' or a `struct field', or whatever.

> Doing it for struct symbol would be a good idea, I think, but a better
> approach would be:
>   - start the environments properly, using a new enum.
>   - Separate out those things which need to be "different kinds of
>     struct symbol", and keep the factoring at the environment level.
>   - Look up environment entries, not struct symbol's.  That way we can
>     have a hope of keeping the right names attached to types, for
>     instance.

By the last point here, are you suggesting that everyone hand around
pointers to `struct environment_entry' objects, rather than pointers
to `struct type', `struct field', etc.?  That would lose some
typechecking, and some clarity.  If space is the concern, I think I'd
rather see both the environment entry and the symbol/field/etc. have
`name' fields, that perhaps point to the same string.