"Walter" <newshound@digitalmars.com> wrote in message news:cursen$2i8n$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:curo45$2eea$1@digitaldaemon.com...
>> Circular imports are only a problem if the static initializers have
> circular
>> dependencies. One way out is to make this more explicit by putting the dependencies on the static ctors somehow.
>
> While this would work, I think in real life it would be very brittle and
> result in many bugs. The trouble is when maintenance programmers change
> the
> code, will they change the dependency list, and if they do, will they get
> it
> right? This is like the syntax in gcc for telling the compiler which
> registers are used by the inline assembly, except it's even harder for the
> programmer to get right.


And the current system isn't more brittle? There have already been two people who tripped up over it. If someone adds static ctors to two modules they would have to remember to check if they have to add empty static ctors to all the modules "between" them. Remember the static ctor dependencies will be optional and should only be needed when the module in question is involved in a circular dependency

> Essentially, any language feature where the programmer has to express something twice is a bug. C header files are one such <g>.

One wouldn't have to express it twice. Only when more information is needed to diagnose the problem. The counter argument to the current design is that it forces programmers to add "dead code" to their codebase - if they are lucky enough to remember to add that dead code. Wouldn't it be better to give more information right at the problem site (the static ctors that have a circular dependency) than spread dead-code around the entire codebase?

"Walter" <newshound@digitalmars.com> wrote in message news:cusdno$20i$1@digitaldaemon.com...
>
> "Kris" <Kris_member@pathlink.com> wrote in message news:curtjf$2j35$1@digitaldaemon.com...
>> Excellent!
>>
>> May I suggest something?
>
> Too late! I already figured out a way to fix it. It's 2 lines of code
> added
> to dmd <g>.

oh cool! Then forget about my suggestion about adding more info to the static ctors. If you fixed the bug without changing how circular dependencies work then that is the best solution.

"Walter" <newshound@digitalmars.com> wrote in message news:cus7l4$2sa5$1@digitaldaemon.com...
>
> "John Reimer" <brk_6502@yahoo.com> wrote in message news:pan.2005.02.15.04.27.18.367664@yahoo.com...
>> > Essentially, any language feature where the programmer has to express something twice is a bug. C header files are one such <g>.
>>
>> Well, I'd say that D import modules amount to the same thing in instances of closed source libraries that provided stripped modules for public use. I don't think the world is completely opensource yet. :-)
>
> That isn't a problem with the language, it's more a weakness of the
> current
> implementation. There's no reason why, when compiling a module, the
> compiler
> cannot emit a "symbol" file. Then, when another module imports it, the
> "symbol" file is read instead. The "symbol" file will only have in it what
> is necessary for importation.
>
> That was the original design for DMD, but to get the compiler done and
> working I took the expedient route of just reparsing the import source
> file
> instead.
>

Does this mean that symbol files will be added in the future?

Walter schrieb:
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> news:curo45$2eea$1@digitaldaemon.com...
> 
>>Circular imports are only a problem if the static initializers have
> 
> circular
> 
>>dependencies. One way out is to make this more explicit by putting the
>>dependencies on the static ctors somehow.
> 
> 
> While this would work, I think in real life it would be very brittle and
> result in many bugs. The trouble is when maintenance programmers change the
> code, will they change the dependency list, and if they do, will they get it
> right? This is like the syntax in gcc for telling the compiler which
> registers are used by the inline assembly, except it's even harder for the
> programmer to get right.
> 
> Essentially, any language feature where the programmer has to express
> something twice is a bug. C header files are one such <g>.
> 
> 

Perhaps you don't have to specify it twice but only if you want to resolve a circular import issue. For example:

=====
module a;
import b;

static this()
{
}

module b;
import a;

static this()
// State that a.this() is required
{
}

So if you don't specify it, the order of the execution will be "default".

Walter wrote:
> "Kris" <Kris_member@pathlink.com> wrote in message
> news:curtjf$2j35$1@digitaldaemon.com...
> 
>>Excellent!
>>
>>May I suggest something?
> 
> 
> Too late! I already figured out a way to fix it. It's 2 lines of code added
> to dmd <g>.
> 
> 

Good; and thanks!

"Nick Sabalausky" <z@a.a> wrote in message news:cusu9i$guj$1@digitaldaemon.com...
> Does this mean that symbol files will be added in the future?

Yes, since it's clear that they add significant value.

In article <cuu836$1tsi$2@digitaldaemon.com>, Walter says...
>
>
>"Nick Sabalausky" <z@a.a> wrote in message news:cusu9i$guj$1@digitaldaemon.com...
>> Does this mean that symbol files will be added in the future?
>
>Yes, since it's clear that they add significant value.
>
>

Does what you have planned for the '"symbol" file import' also allow for function inlining via import (like source file import does now)?

Thanks,

- Dave

Walter wrote:
> "John Reimer" <brk_6502@yahoo.com> wrote in message
> news:pan.2005.02.15.04.27.18.367664@yahoo.com...
> 
>>>Essentially, any language feature where the programmer has to express
>>>something twice is a bug. C header files are one such <g>.
>>
>>Well, I'd say that D import modules amount to the same thing in instances
>>of closed source libraries that provided stripped modules for public
>>use. I don't think the world is completely opensource yet. :-)
> 
> 
> That isn't a problem with the language, it's more a weakness of the current
> implementation. There's no reason why, when compiling a module, the compiler
> cannot emit a "symbol" file. Then, when another module imports it, the
> "symbol" file is read instead. The "symbol" file will only have in it what
> is necessary for importation.
> 
> That was the original design for DMD, but to get the compiler done and
> working I took the expedient route of just reparsing the import source file
> instead.
> 
> 

Yes, I see your point.  I very much look forward to a time when that "symbol" file is generated by the compiler.

"Dave" <Dave_member@pathlink.com> wrote in message news:cuua18$1vhe$1@digitaldaemon.com...
> In article <cuu836$1tsi$2@digitaldaemon.com>, Walter says...
> >
> >
> >"Nick Sabalausky" <z@a.a> wrote in message news:cusu9i$guj$1@digitaldaemon.com...
> >> Does this mean that symbol files will be added in the future?
> >
> >Yes, since it's clear that they add significant value.
> >
> >
>
> Does what you have planned for the '"symbol" file import' also allow for function inlining via import (like source file import does now)?

Yes.

In article <cv0d40$13dn$2@digitaldaemon.com>, Walter says...
>
>
>"Dave" <Dave_member@pathlink.com> wrote in message news:cuua18$1vhe$1@digitaldaemon.com...
>> In article <cuu836$1tsi$2@digitaldaemon.com>, Walter says...
>> >
>> >
>> >"Nick Sabalausky" <z@a.a> wrote in message news:cusu9i$guj$1@digitaldaemon.com...
>> >> Does this mean that symbol files will be added in the future?
>> >
>> >Yes, since it's clear that they add significant value.
>> >
>> >
>>
>> Does what you have planned for the '"symbol" file import' also allow for function inlining via import (like source file import does now)?
>
>Yes.
>

Great and Thanks!

- Dave