Walter Bright:
> Excess isn't the problem, I want to see if import cycles is.

Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

Bye,
bearophile

On Fri, Dec 19, 2008 at 6:51 PM, BCS <ao@pathlink.com> wrote:
> Reply to Walter,
>
>
>> That is the cyclic import problem. Can you check again to see if you have cyclic imports?
>>
>
> could you add a flag to DMD that will give a waning on cyclical imports?

http://www.shfls.org/w/d/dimple/

Cyclic imports show up in red.  I love it.

Bill Baxter Wrote:

> On Sat, Dec 20, 2008 at 10:39 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> > BCS wrote:
> >>>
> >>> That is the cyclic import problem. Can you check again to see if you have cyclic imports?
> >>>
> >>
> >> could you add a flag to DMD that will give a waning on cyclical imports?
> >
> > I could, but in the meantime I want to find the source of the slowdown.
> 
> Without such a warning it's a bit difficult to track down if there are
> cyclic imports or not.  At least in my code.
> I was hoping John C's example is maybe of  a little more manageable size.
> 
> --bb

I'll look into it.

John.

bearophile wrote:

> Walter Bright:
>> Excess isn't the problem, I want to see if import cycles is.
> 
> Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

Cyclic imports is very often a sign of bad design, it typically mean (if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

bearophile wrote:
> Walter Bright:
>> Excess isn't the problem, I want to see if import cycles is.
> 
> Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

Cyclic imports are a bad idea in general because of the impact they have on verifiability (unit testing).  But as you say, sometimes they're unavoidable.


Sean

Hello Sean,

> bearophile wrote:
> 
>> Walter Bright:
>> 
>>> Excess isn't the problem, I want to see if import cycles is.
>>> 
>> Generally all the modules in my dlibs import each other. This is
>> nearly unavoidable, if a module contains string functions, and
>> another one contains math stuff, the string module will want to use
>> some math stuff and the math module may need string representations
>> and processing. In the D specs I haven't seen an advice to not use
>> cyclic imports, so I don't want such compiler flag, I prefer a
>> compiler able to manage such cyclic imports efficiently.
>> 
> Cyclic imports are a bad idea in general because of the impact they
> have on verifiability (unit testing).  But as you say, sometimes
> they're unavoidable.
> 
> Sean
> 


I'd going to wager that they are /often/ unavoidable, especially in ported projects from other languages that have either no concept or a different concept of modules/packages.

DWT is perhaps the single worse example of cyclic imports.  I'm not sure how the design could have been improved in Java's SWT.  All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D.  

Static initialization has also been a problem in DWT such that a few significant workarounds were necessary.

I agree that the interdepencies should be avoided in all new projects designed specifically for D.  I'm just not sure what the solution would be for the great mass of ported software.

-JJR

Hello Lars,

> bearophile wrote:
> 
>> Walter Bright:
>> 
>>> Excess isn't the problem, I want to see if import cycles is.
>>> 
>> Generally all the modules in my dlibs import each other. This is
>> nearly unavoidable, if a module contains string functions, and
>> another one contains math stuff, the string module will want to use
>> some math stuff and the math module may need string representations
>> and processing. In the D specs I haven't seen an advice to not use
>> cyclic imports, so I don't want such compiler flag, I prefer a
>> compiler able to manage such cyclic imports efficiently.
>> 
> Cyclic imports is very often a sign of bad design, it typically mean
> (if it is unavoidable), that the modules shouldn't be separated in the
> first place. And in D it _is_ a bad idea because static initialization
> cannot depend on each other, that is cyclic imports of modules with
> static ctors.
> 


And yet it appears practically unavoidable in D in many situations, especially in porting software that with C, Java, or C++ heritage.  Since other languages don't necessarily have the same module/package concept (except perhaps Java is the closest), porting such projects over to D inevitably triggers the cyclic dependency problem.  The problem does indeed exacerbate when static initialization is thrown into the equation.

One would have to build a D project from scratch in order to avoid it (eg Tango).  The majority of projects, however, are going to be based on ported code.  Thus, "bad design" becomes somewhat meaningless practically speaking, although I certainly wish there were an easy solution to the cyclic imports other than including all files in the same module. :)

-JJR

On Sat, 20 Dec 2008 18:45:24 +0100, Lars Ivar Igesund wrote:

> bearophile wrote:
> 
>> Walter Bright:
>>> Excess isn't the problem, I want to see if import cycles is.
>> 
>> Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.
> 
> Cyclic imports is very often a sign of bad design, it typically mean (if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

Just thinking out aloud ...

If two modules import each other and this can be 'fixed' by instead having both modules as a single module, what is stopping the compiler from just pretending that they are a single module for compilation purposes?

This does assume that they are to be compiled at the same time rather than one-file-at-a-time.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Hello Derek,

> On Sat, 20 Dec 2008 18:45:24 +0100, Lars Ivar Igesund wrote:
> 
>> bearophile wrote:
>> 
>>> Walter Bright:
>>> 
>>>> Excess isn't the problem, I want to see if import cycles is.
>>>> 
>>> Generally all the modules in my dlibs import each other. This is
>>> nearly unavoidable, if a module contains string functions, and
>>> another one contains math stuff, the string module will want to use
>>> some math stuff and the math module may need string representations
>>> and processing. In the D specs I haven't seen an advice to not use
>>> cyclic imports, so I don't want such compiler flag, I prefer a
>>> compiler able to manage such cyclic imports efficiently.
>>> 
>> Cyclic imports is very often a sign of bad design, it typically mean
>> (if it is unavoidable), that the modules shouldn't be separated in
>> the first place. And in D it _is_ a bad idea because static
>> initialization cannot depend on each other, that is cyclic imports of
>> modules with static ctors.
>> 
> Just thinking out aloud ...
> 
> If two modules import each other and this can be 'fixed' by instead
> having both modules as a single module, what is stopping the compiler
> from just pretending that they are a single module for compilation
> purposes?
> 
> This does assume that they are to be compiled at the same time rather
> than one-file-at-a-time.
> 


Interesting idea. :)

Maybe there would be issues with module ctors and __FILE__/__LINE__ expressions too?
Also it may mess up module info, debug, and other object attributes.

-JJR

bearophile wrote:
> Walter Bright:
>> Excess isn't the problem, I want to see if import cycles is.
> 
> Generally all the modules in my dlibs import each other. This is
> nearly unavoidable, if a module contains string functions, and
> another one contains math stuff, the string module will want to use
> some math stuff and the math module may need string representations
> and processing. In the D specs I haven't seen an advice to not use
> cyclic imports, so I don't want such compiler flag, I prefer a
> compiler able to manage such cyclic imports efficiently.

I understand your point, I am just trying to isolate the source of the problem rather than trying random things.