On Friday, 30 March 2012 at 10:22:18 UTC, Walter Bright wrote:
On 3/30/2012 2:15 AM, Nick Sabalausky wrote:
Andrei and I have talked about it, and we think it is
because of
difficulties in breaking a module up into submodules of a
package.
We think it's something we need to address.
Eh? Other people have voiced concerns over that since waaay
back in even
pre-D1 times. In particular, many people have argued for
allowing modules
with the same name as a package. Ie: you could have both
module "foo" and
module "foo.bar". The reasons they gave for wanting this are
right along the
lines of what you're talking about here. Eventually they got
the message
that it wasn't gonna happen and they gave up asking for it.
Or is there a separate problem you're refering to?
No, that's it. What brings it to the fore is, as I said, the
kitchen-sink module that is becoming prevalent.
I'm confused. I thought that The kitchen-sink approach was a
deliberate design decision. I also don't see how the language is
at fault here - some libraries opted for a all.d module that
public imports the other modules which cleanly solves the problem.
This can be trivially solved by a convention of adding a _.d or
all.d or whatever agreed upon module at the package level. Sure,
the above mentioned enhancement will remove the need for this
extra tiny step. But this is merely eliminating a minor
inconvenience, not some huge flaw of the language that prevents
good design and proper organization.
