Many questions

[Yigal Chripun]

bearophile wrote:
> Yigal Chripun:
>> the downside to the current system is when you have one class in a file, 
>> the full name of it will be SomeClass.SomeClass instead of just 
>> SomeClass. (because of the redundancy of the module decl. in this case)
> 
> Generally if classes or functions are small, you put more than one of them (related ones) in the same module.

sure. nothing I said contradicts this. you can have however many 
constructs in one file. Either make only one of them as public, or put 
all of them inside a "module" declaration like you do now.

> 
> 
>> Ideally, I'd want at most one public root entity per file.
> 
> That's the Java ideal world.

well, the trade-off to consider is:
on the one hand - if you go for namespaces like solution you get most 
flexible design. i.e one file with a bunch of small public classes (for 
example exceptions) will be exactly the same as many small files with 
one class in each if in both cases you define all those classes to 
belong to one namespace.
on the other hand - this removes the ability to know in which file a 
class is defined.

I think that in such a case it's a reasonable trade off to have:
module exceptions {
   class A {}
   class B {}
   ...
}
where exceptions is the "root" element of the file.

so, exceptions.SomeException can be both a file called exceptions that 
contains a SomeException class and a exception directory with a file 
called SomeException that contains that specific class. (also, you can 
mix both ways, and have only some of the exceptions in separate files).

currently, if I have a file with a bunch of classes, and over time the 
file became too big and I decided to split it to several smaller files, 
such a split will affect the code because package.module.classA will 
become package.module.classA.classA after such a split.

> Bye,
> bearophile

another idea, is that if you have:
package
  |\
  | exceptions
  |    \
  |     classA.d
  |     classB.d
  |
exceptions.d

classA and classB files contain single classes by the same respective 
names, and exceptions.d contains a bunch of smaller classes in one file.
in this case the compiler could "fuse" together the paths so logically 
in the code you'll have package.exceptions.[class_name] where class_name 
is one of classA, classB or any of the classes defined in exceptions.d

does that sound reasonable? this is as close as possible I can think of 
to full namespaces without loosing the ability to find where some code 
is located in the file system.

in this case go to 'package' dir, inside you need to check the 
exceptions.d file. if desired class isn't in this file you know to go 
check the 'exceptions' dir, and so forth.