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

[Daniel Berlin <dan@dberlin.org>]

> > - How would we introduce this incrementally?
> 
> Do we want to?
> 
> No, I'm serious.  Incremental solutions are more practical to
> implement, but they will come with more baggage.  Baggage will haunt us
> for a very long time.  If we can completely handle non-minimal-symbol
> lookup in this way, that's a big win.
> 

You might be able to pull something off like i did on the 
new-typesystem-branch (which is unfinished, but quite far along. It was 
left ina  non-compiling stabs because i was in the midst of stabs fixes 
when i stopped working on it).

I modified a single type class at a time, replacing it with a compatible 
structure with the added members, then changed the functions gradually to 
fill in the extra members, then use the extra members, then not use the 
old members, then removed the old members.  Somewhere in there ,I 
created new type creation functions (one for each type class), and changed 
the symbol readers to use them when approriate.

Adding a struct environment is probably comparable in the amount of 
work/places to touch.

I can tell you that while I did succeeed in keeping a working gdb at 
all times, even with a mix of new type structures and old (which are 
completely different beasts), it was *amazingly* tedious to do it this 
way.

It's not just a matter of global search and replace, the rewriting 
required is mundane and repetitive, but a step above what simple global 
search and replace would do, so you end up doing it by hand (you'd need 
to write a pass for a source-source translator or something to do it 
automatically).

It was at least 2x the work it would have been to not do it incrementally.
But it's also less disheartening then dealing with 8 million compile 
errors at once, and trying to hunt down logic bugs after making a million 
changes.

--Dan