Many questions

[Christopher Wright]

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.