Fixing cyclic import static construction problems

[Dmitry Olshansky]

11/29/2012 4:17 PM, Jonathan M Davis пишет:
> On Thursday, November 29, 2012 12:39:19 Paulo Pinto wrote:
>> On Thursday, 29 November 2012 at 03:19:55 UTC, Andrei
>>
>> Alexandrescu wrote:
>>> On 11/28/12 9:34 PM, Walter Bright wrote:
>>>> For discussion:
>>> [snip]
>>>
>>> I'd say we better finish const, immutable, and shared first.
>>>
>>> Andrei
>>
>> +1
>>
>> Fully agree.
>>
>> Cyclic imports are a minor nuisance that can be easily solvable
>> with better code architecture.
>>
>> Turbo Pascal/Delphi is the only language that I know fully allows
>> cyclic dependencies between modules. So this is not that
>> important for most people.
>
> Basic features in the language require static constructors (e.g. static
> variables frequently do), and some things just can't be done without them.
> Andrei's std.benchmark proposal actually doesn't work, because in order to do
> what it does, in needs to mixin in a static constructor and static destructor
> (to set up the benchmarking and record it at the end, I believe). That
> completely falls apart due to cyclical imports.

I do suspect it could be healed by inverting the control flow (or rather 
bringing it back).

Basically there is this pattern:

module a;
...
mixin ScheduleForBenchmark;

Same for module b, c, d...

And then compiling all of this with -version benchmark should run the 
benchmarks.

It already has another problem: there has to be D main stuffed in there 
somehow. It can't be in std.benchmark as it then will have to be 
included in phobos(.lib|.a) and it can't be magically turned on/off with 
-version switch either unless std.benchmark is passed directly to the 
compiler.

The other solution would be: make a separate my_benchmark.d module that 
contains:
import a,b,c,d...;

void main(){
    runBenchmarks!(a,b,c,d...)();
}

And that's it.
In any case I usually like having some separation between different sets 
of modules to benchmark so that I can start them in a 'clean room' scenario.

> It doesn't actually cause any
> true circular dependencies, but it's treated as such anyway. A _lot_ of us
> have run into this problem and a number of us consider it to be a huge design
> problem in the language. Personally, I'd put it towards the top of design
> mistakes at this point, and I'm very glad to see Walter actually finally being
> willing to do something about this. In the past when I've brought up similar
> solutions, he's been completely opposed to them.
>
> Yes, we have other major issues that need to be resolved, and those may very
> well be of a higher priority, but this is still a very import issue, and it's
> the sort of issue that can probably be implemented with minimal effort. The
> main thing is getting Walter to agree to it and how it will be done. Once a
> decision is made, it wouldn't surprise me if someone like Kenji were able to
> get it done very quickly.
>
> - Jonathan M Davis
>
-- 
Dmitry Olshansky