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

[Gianni Mariani <gianni at mariani dot ws>]

As a complete digression:

Although this problem might need to be solved in the fashion presented 
here, I can't help but think we're trying to solve the wrong problem.

Much of what is discussed here is language and compiler specific.  My 
generic approach to solving this kind of problem is to provide an 
abstraction layer where all the facilities are provided for in a API 
(abstract base interface class); the mapping is then language and 
compiler specific.  The burden is then on the compiler writer to provide 
the symbol binding mechanism/implementation which is where it belongs.

This then buys all kinds of nice things like unit testability.  If the 
compiler writer makes a change, the compiler tests fail way before it 
even gets to running gdb.

In other words, "Place the responsibility with the knowledge".

The question is - how do you provide an abstraction that makes sense for 
all languages ? (or at least *most* languages).

BTW- "Amazingly tedious refactoring" is somthing that a editor macro can 
help with.  I constantly have people in my development team who want to 
make global changes and I end up doing them because I've taken the time 
to learn how to use my editor's keyboard macros.  The reason you 
*should* use them is that you can guarentee a consistant change.

So how about this silly challenge:
    a) Someone define a new interface for symbol look up.
    b) Someone implement the interface so it is in an independant module.
    c) I'll mod the code to use the new interface

I'll bet a keg of beer I can do c) it in less time it takes someone to 
do a) and b).

.... I feel I'm going to regret this .... :)

Daniel Berlin wrote:

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