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.
