> 
> The #1 show-stopper for me was lack of shared object (.so) support under
> Linux; virtually mandated by my audience (Apache/LAMP).  (A workaround
> like FastCGI is simply not appealing to customers.)  This topic
> discussed many times before on this NG.
> 
> 
I also had done a fair amount of work, and foundered on the inability to dynamically load anything without it being a big deal.

Like you say, it has been brought up many many times. Everyone says yes, this is a real show-stopper, then the thread dies down and so on.

Steve

Jacob Carlborg wrote:
> On 3/10/10 01:15, Walter Bright wrote:
>> Ellery Newcomer wrote:
>>> I hate the restriction on modules with static constructors and cyclic
>>> dependencies. IMO it's the most patronizing 'feature' D has.
>>
>> I understand, but the alternative is the essentially random order of
>> execution that C++ has.
> 
> How does Java handle this ?

Static initialization blocks are associated to classes. They are run when the class is loaded. So it depends on the order classes are loaded in your program (it's the order in which you instantiate them).

---
public class A {
	static {
		System.out.println("A loading");
		B b = new B();
		System.out.println("A loaded");
	}
}

public class B {
	static {
		System.out.println("B loading");
		A a = new A();
		System.out.println("B loaded");
	}
}

public class C {
	
	public static void main(String[] args) {
		A a = new A();
// Prints:
// A loading
// B loading
// B loaded
// A loaded
	}

}

public class D {
	
	public static void main(String[] args) {
		B b = new B();
// Prints:
// B loading
// A loading
// A loaded
// B loaded
	}

}

On 3/10/10 17:22, Ary Borenszweig wrote:
> Jacob Carlborg wrote:
>> On 3/10/10 01:15, Walter Bright wrote:
>>> Ellery Newcomer wrote:
>>>> I hate the restriction on modules with static constructors and cyclic
>>>> dependencies. IMO it's the most patronizing 'feature' D has.
>>>
>>> I understand, but the alternative is the essentially random order of
>>> execution that C++ has.
>>
>> How does Java handle this ?
>
> Static initialization blocks are associated to classes. They are run
> when the class is loaded. So it depends on the order classes are loaded
> in your program (it's the order in which you instantiate them).
>
> ---
> public class A {
> static {
> System.out.println("A loading");
> B b = new B();
> System.out.println("A loaded");
> }
> }
>
> public class B {
> static {
> System.out.println("B loading");
> A a = new A();
> System.out.println("B loaded");
> }
> }
>
> public class C {
>
> public static void main(String[] args) {
> A a = new A();
> // Prints:
> // A loading
> // B loading
> // B loaded
> // A loaded
> }
>
> }
>
> public class D {
>
> public static void main(String[] args) {
> B b = new B();
> // Prints:
> // B loading
> // A loading
> // A loaded
> // B loaded
> }
>
> }

I forgot for a second that Java forces you to put everything in classes.

Jacob Carlborg wrote:
> I've always wonder why that is. I mean if I put an empty static constructor in two modules and they import each other I get a circular reference error. Usually when I use static constructors they don't depend on the order of each other. Can't this be fixed if the static constructors don't depend on each other?


I don't know if there's a reasonable way of determining if they depend on each other, so dmd assumes they do.

On 10.03.2010 13:13, Walter Bright wrote:
> Walter Bright wrote:
>> Max Samukha wrote:
>>> 2. A third module cannot be used. At least, we haven't been able to
>>> figure out how to do that. Probably, something could be hacked up if
>>> this bug (feature) is fixed
>>> http://d.puremagic.com/issues/show_bug.cgi?id=2671
>>
>> Thanks, I'll have a look at it.
>
> The example in the bug report works on D1 and D2. I cannot reproduce the
> error. I marked it as "worksforme"; if I've got the test case wrong
> please reopen it.

My example is incorrect, sorry. b and c should be circularly imported:

module a;

template Foo(int i)
{
    static this()
    {
    }
}

void main() { }
----

module b;

import a;
import c;

alias Foo!(1) foo;
----

module c;

import a;
import b;

alias Foo!(2) foo;
----
Error: circular initialization dependency with module b

Following the logic that Foo is not a mixin template, I hoped to cheat the compiler so that the static constructors ran during a's initialization, avoiding the circular dependency error. I was wrong.

Still looking for a solution. Basically, there should be a way to enable the following:

module a;

template Foo()
{
    static int a;
    static this()
    {
       a = 42;
    }
}

----
module b;
import c;
import a;

mixin Foo;

----
module c;
import b;
import a;

mixin Foo;

On 03/10/2010 12:14 PM, Walter Bright wrote:
> Jacob Carlborg wrote:
>> I've always wonder why that is. I mean if I put an empty static
>> constructor in two modules and they import each other I get a circular
>> reference error. Usually when I use static constructors they don't
>> depend on the order of each other. Can't this be fixed if the static
>> constructors don't depend on each other?
>
>
> I don't know if there's a reasonable way of determining if they depend
> on each other, so dmd assumes they do.

Maybe do a bit of analysis that can tell whether any static ctors in a module use symbols from any other module and use that to determine module dependencies? It wouldn't fix the problem completely, but it would make it a bit more fine grained, and would probably remove 90% of the false positives.

Nick Sabalausky Wrote:

> "Justin Johansson" <no@spam.com> wrote in message news:hn6evv$hl7$1@digitalmars.com...
> > Walter Bright Wrote:
> >
> >> Justin Johansson wrote:
> >> > Having spent six months developing a significant app in D only to find
> >> > impediments to
> >> > practical completion of the project and ultimate deployment,
> >>
> >> Which ones did you find to be blocking?
> >
> > (My time zone is way different to yours and gotta dash to work soon so will have to be brief).
> >
> > (Comments in relation to D1)
> >
> > The #1 show-stopper for me was lack of shared object (.so) support under
> > Linux; virtually
> > mandated by my audience (Apache/LAMP).  (A workaround like FastCGI is
> > simply not
> > appealing to customers.)  This topic discussed many times before on this
> > NG.
> >
> 
> When you have a chance, I'm curious to hear why you feel something like FastCGI is unappealing to customers compared to .so. I assume there's more to it than it just not being "trendy" enough. (For me personally, the issue is moot b/c my clients are generally on shared hosting from questionable providers, so I pretty much have to stick with PHP or Haxe. Or ASP, depending on the client).

Hi Nick,

The product I'm developing is a library that will be/can be integrated into a
number of Apache modules (e.g. mod_python) for webby-type applications
(e.g. SOA) and needs to execute in-process.  It cannot be easily integrated
in-process-wise with FastCGI.  The only other option is to offer it as statically linked
library but for a variety of reasons (convenience of deployment, commercial etc),
dynamic linking via a shared library is really the only way to go.

Probably my choice of words (unappealing) may have misled you into thinking that FastCGI might have been an option for me but it is not.

Cheers, JJ

Ellery Newcomer wrote:
> Maybe do a bit of analysis that can tell whether any static ctors in a module use symbols from any other module and use that to determine module dependencies?

This is a transitive thing. Furthermore, if you do anything nontrivial, you'll be referencing other module symbols. And finally, if you add some debugging code like a print statement, suddenly your code will no longer run.

Max Samukha wrote:
> Still looking for a solution. Basically, there should be a way to enable the following:
> 
> module a;
> 
> template Foo()
> {
>     static int a;
>     static this()
>     {
>        a = 42;
>     }
> }
> 
> ----
> module b;
> import c;
> import a;
> 
> mixin Foo;
> 
> ----
> module c;
> import b;
> import a;
> 
> mixin Foo;

template Foo()
{
    static int _a;
    static int a()
    {
        static bool _a_inited;
        if (!_a_inited)
        {    _a_inited = true;
             _a = 42;
        }
        return _a;
    }
}

I just had a crazy thought: how about allow things to explicitly state static-constructor dependencies? By default, it would work as it does now, all constructors in all imported modules get run before any in this module but if an explicit list is given, then only that list need be run first.

My first thought was to only do this at the module level with something like this:

module foo.bar : foo.baz, foo.baz; // run first, even thought not imported

import foo.bar;
import foo.bing; // constructors need not be run first

It might be handy to allow finer grained specification of both the ends, maybe putting the list per constructor and allowing the list to include classes for instance.

-- 
... <IXOYE><