grauzone wrote:
Christopher Wright wrote:
It *is* possible, by use of public imports.
Are you splitting one file into many? Public import the other modules.
Are you merging many files into one? Leave the other files with just a
public import of the merged file.
Nice story. In reality you face all kinds of problems: like circular
dependency bugs, public/private/package are not fine enough (friend
modules or a fixed package attribute would be nice), and you still can't
split the implementation of a class across several files. But yes, I
guess I could implement a CTFE driven preprocessor using import(), which
would solve all problems. And then you switch to another language,
because all the bugs and kludges just isn't it worth.
Then: it *should* be possible, but compiler bugs sometimes prevent it,
and there is an old issue with circular imports with static constructors
that you will often run into, and you might want fine-grained access
control that you won't always have if you split a file into multiple
subpackages as well as multiple files.
However, I would like to see use cases for putting one module in
multiple files, and for putting one class in multiple files.
The only use case that springs to mind for one class in several files is
when part of the class is generated by a tool, though you can handle
that with inheritance instead.
I see no use case for having one module in multiple files, though -- the
only benefit would be private access to things defined in other files.
I've never been big on making stuff private, though.
