Andrei Alexandrescu wrote:
yigal chripun wrote:
Andrei Alexandrescu Wrote:
yigal chripun wrote:
Andrei Alexandrescu Wrote:
Is it appropriate to define multiple classes, structs,
templates, etc within a single module? What considerations
should inform the decision regarding the placement of module
boundaries?
I think it's appropriate because many pieces of functionality
come as a bundle. The rule of thumb is, module provides the
functionality, and it's up to the designer to decide what that
entails.
Andrei
The rule of thumb above is good in theory but in practice such a
given bundle of functionality can produce a 30_000 line file.
while all those lines should be "bundled" conceptually together,
D's restriction of module == file makes for a huge file that is a
hassle to work with.
yes, a "module" should represent a conceptual bundle of
functionallity but forcing this into one huge file is wrong.
I think public import can help with that.
Andrei
That is just a work-around and not a full solution.
Why?
this is a weak
spot in D which I'd like to see fixed.
Why is it a weak spot? What problems mar its advantages?
I think the approach with public imports should work in principle
(although would probably require making a package for such 'module
bundles' to have package-level field visibility, since private members
would not be accessible across modules), but currently the DMD frontend
fails at circular dependencies making this approach impossible.
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
