> 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

Reply via email to