Developing a plan for D2.0: Getting everything on the table

[Tom S]

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