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

[Jim Blandy <jimb@redhat.com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> As much of a pain as they are, I recommend a CVS branch for this.  Then
> we can see how it comes together with some history and a little less
> destabilization.  We still need to know where we're going first, of
> course.

So you're suggesting that we do all the work first on a branch, and
then once we've got that the way we want, we merge it piece-wise into
the trunk?

> >   a) The symbol table stores names either way: with an explicit
> >      namespace tree, or with qualified names sitting directly in the
> >      symbol table.  (When I say "namespace", please understand that to
> >      also include classes, etc.)  Any given symbol is stored only one
> >      way or the other, but any given symbol table can hold a mix of
> >      symbols in each form.  Symbols stored in the explicit tree would
> >      have a `fully_qualified_name' field, so symtab clients expecting
> >      to see fully qualified names would still get them.
> 
> OK so far... we might want to take the path of least resistence, leave
> the name fully qualified, and add an unqualified_name.

Sure.

> >   b) The object representing a namespace keeps around the prefix it
> >      corresponds to (`std::' or `A::B::' or whatever), so that lookups of
> >      single name components relative to that namespace can find entries
> >      stored in either form.
> > 
> >   c) For backwards compatibility, the symbol lookup function would check
> >      for `::' in symbol names, and do a component-by-component lookup.
> 
> We might also want to check for '.', as per Java (in existing gcj
> versions, at least).

Yes, that's true.

> > - Once the producers are all creating data in the new style, remove
> >   support for it.  Now you've got your new data structure, used as an
> >   opaque datatype.
> 
> And hopefully we'd reach this step, rather than being left with the
> mess in the middle.

Hopefully!  :)

> I like it.  Who wants to start? :)  We probably want to start with
> interfaces, and then see where we need to go from there.

If I write up a concrete proposal for this, I think my keepers will
let me spend time on it.  Sure, let's draft some interfaces.