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

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Apr 08, 2002 at 07:19:14PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > How about -containing- `struct fields', instead of replacing?  i.e. let
> > the name search happen in the `struct environment', as before, but the
> > data items would be fields (could be indicated in a flag in the
> > environment, with a pointer to the type or symbol for the enclosing
> > structure).  I don't think turning members into symbols is a good idea.
> 
> I admit the idea of using `struct symbol' for fields as well as
> variables is pretty weird.  Here's the rationale:
> 
> First, keep in mind that `struct symbol' is sort of a `messy union':
> it's used for a lot of distinct purposes, and it contains all the
> members any of those purposes might need.  The `struct symbol'
> representing a declaration like `struct A' doesn't need its
> ginfo.value field.  The `struct symbol' representing a local variable
> doesn't need its `bfd_section' field.  (I'm not saying this is a great
> way to do things; but it is the way it's done now.)

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,
};

Some duplication between symbol_kind and field_kind that would need to
be decided on, and there's probably other useful kinds. There could
even be a subtype in there if we found it convenient.  For instance:

/* For classes.  */
enum field_kind {
  normal_field,
  static_field,
  base_class, /* Probably not this one, actually.  Better kept in the type?  */
  member_function,
  static_member_fn, /* Might or might not be necessary.  */
};

Then we don't need to have a dummy symbol for every type, etc.  It
would keep searching a little more straightforward.  IMVHO.

There's plenty of details I haven't thought about how to fit in.  Like,
the protections on a member type.  Perhaps the environment really
should dictate a structure for every member of the environment,
opaquely.  We have some wiggle room here.

There's also a question of how many "kinds" of lookup situations we
have - implicit vs. explicit members, for instance.  Some inherit one
way, some another, so we'd need to have separate lookup functions.

Categorizing by an enum is all good.  Reusing address classes, though,
I'm more suspicious of.

Does that make sense?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer