Many questions

[Denis Koroskin]

On Tue, 05 May 2009 09:50:24 +0400, Yigal Chripun <yigal100 at gmail.com> wrote:

> 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.

I believe this is reasonable, but I don't think we will convince Walter for a change.
Either way, this idea needs to be out into bugzilla, or it will be lost.