Eigenpoll : D wish list : Improve module architecture

Desired:
---
system.drawing.ColorEnum.BLACK
system.drawing.Bitmap
system.drawing.Brush
...

Now you put these in system/drawing.d, but once you get a lot of classes you
wish to put source code into seperate files.

Results in:
---
system.drawing.ColorEnum.BLACK <- system/drawing.d (! not possible !)
system.drawing.bitmap.Bitmap <- system/drawing/bitmap.d
system.drawing.brush.Brush <- system/drawing/brush.d
system.SomeClass <- system.d (! not possible !)
...

This however:
---
1. Does not work as packagename != modulename limitation exists (line 1+4)
2. Adds an ugly unnecessary extra package level (line 2+3)
3. Is bad for designing clear APIs that have the "expected design" feeling
4. Bad for implementing big frameworks/libraries

Current "hack/workaround" adding "all.d":
---
system.drawing.all.SomeEnum.Black <- system/drawing/all.d
system.drawing.bitmap.Bitmap <- system/drawing/bitmap.d
system.drawing.brush.Brush <- system/drawing/brush.d
...

Still all issues asside of the 1. remain even with this "hack".

I think it is against the defined goals of the D language to have to use "hacks"
in order to get this behaviour which is even ugly.

Instead it should be practical, logical and offer the "developer expected" way.
The argument "modules are just simpler and better" does not work here anymore.

This is primary about changing handling of source files by the compiler, not
about changing D semantics which already support such desired module layout.

Report this item for cleanup