Christopher Wright wrote:
Fractal wrote:
That's debatable. The hateful thing about namespaces is that they give
you absolutely ZERO clue as to where any particular thing is coming
from.
If I see "tango.io.device.File", I know exactly where the source for
that module is.
-- Daniel
Yes it is true. But the thing is not "where is it". The thing that i
want to remark is "what long".
If you use a namespace, you can write many big classes in separate
files without problem, and also, with the same namespace. (and also
allowing separate a multiplatform class in different files, for each
one).
With modules you are limited in a single file. And it will grow
potentially with multiplatform code, and makes hard to find a error or
line...
Added to it, the amout of version statements.
Also Namespaces can use upper case characters... documentation
indicates that package and module names should be written all in lower
case.
A good point for modules is the permisson to access private or
protected members of types declared in the same module or package,
without the "friend" keyword anywhere.
In namespaces, it can be done by sharing access to all namespace types.
Really module, packages, and namespaces are the same thing. The unique
thing that i want, is the possibility of use many files as one (for
modules)
Modules are compilation units. This makes them different from namespaces.
Packages are for the compiler to find source code. Namespaces are for
humans to find source code. These have sufficient overlap that they have
been unified.
For modules to do what you want, a module cannot be the unit of
compilation. What then will be the unit of compilation? And why is this
feature important enough to merit the change?
in my opinion a more flexible design is:
namespaces can map both to packages/dirs (as it is now) _and_ files for
added flexibility, and compilation units will be files.
I don't think splitting one class/struct/etc to several files is good
design, there are better ways to acomplish this, like defining platform
specific behaviors as mixins:
template foo_win32 {}
template foo_linux {}
and in the class mix-in the appropriate mixin.
*but*, I do think that splitting one file that got too big over time or
uniting a bunch of small files into one should be possible.
