Le 30/03/2012 12:57, foobar a écrit :
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.
all.d this the de facto standard here. I think it should become an
official guideline.
