Many questions

[Yigal Chripun]

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.