> Asger seems to want to make extensive use of namespaces and to a certain > extent I can see that as being a good way to enforce the notion of > ownership to the various modules. So we could have a gui namespace and an > Inset namespace among others. If we then use namespaces in our code we > can use namespaces from stl (which involves using different headers). Yes, I would like to use namespaces more. My feeling is that the bad things about global functions and variables does not exists anymore when you have namespaces. Suddenly, there is nothing wrong with having global functions and variables, and this change opens up some methods of coding that were previously packed away as bad coding style. With namespaces, I feel it's easier to let the code express what things are. For instance, the encoding facility is a global means of performing encoding conversions, that does not depend on any state or context. So I don't see why this feature should not just be exactly that in the code: an independent global function that does the conversion. Regarding whether we should *require* support for namespaces from the compiler or not: I have no real opinion on this. I'm sure that we can make things work without proper namespace support, and that is a good thing. The important thing is that the developers will be able to exploit the concept of namespaces, and if their compiler is up to it, get the extra safety from the compiler. I find it hard to make a list of things that we want from the compiler in advance. I'm more into the lazy style: Just code, and then take care of the problems when they appear. That's what we have been doing so far, and it seems to work pretty well. Of course, we are demanding more things from the compilers now, and it might turn out that we have to set some minimum requirements, but until we know more about the problems, it's hard to say what those are. Greets, Asger