Re: Static constructors in circularly imported modules - again

2010-05-29 Thread Eldar Insafutdinov
Max Samukha Wrote: On 27.05.2010 13:37, Max Samukha wrote: There was a discussion about those a while ago that terminated with Andrei's authoritative it would be a step backward. I am not entirely convinced that there had been a step forward in the first place. Defining static

Re: Static constructors in circularly imported modules - again

2010-05-28 Thread Max Samukha
On 27.05.2010 13:37, Max Samukha wrote: There was a discussion about those a while ago that terminated with Andrei's authoritative it would be a step backward. I am not entirely convinced that there had been a step forward in the first place. Defining static construction order to be determined

Static constructors in circularly imported modules - again

2010-05-27 Thread Max Samukha
There was a discussion about those a while ago that terminated with Andrei's authoritative it would be a step backward. I am not entirely convinced that there had been a step forward in the first place. Defining static construction order to be determined by the module import graph had been a

Re: Static constructors in circularly imported modules - again

2010-05-27 Thread Max Samukha
On 05/27/2010 01:37 PM, Max Samukha wrote: module a; mixin template Foo() { static immutable Object foo; shared static this() { foo = cast(immutable)new Object; } } module b; import a; import c; mixin Foo; module c; import a; import b; mixin Foo; In this scenario one is forced

Re: Static constructors in circularly imported modules - again

2010-05-27 Thread Jason House
Max Samukha Wrote: There was a discussion about those a while ago that terminated with Andrei's authoritative it would be a step backward. I am not entirely convinced that there had been a step forward in the first place. Defining static construction order to be determined by the module

Re: Static constructors in circularly imported modules - again

2010-05-27 Thread Max Samukha
On 05/27/2010 03:47 PM, Jason House wrote: In module b, delete the import of c. In module c, delete the import of b. Your sample code will then compile and run. It probably wouldn't do what you want though; you'll have two globals (b.foo and c.foo). I suspect what you really want is one

Re: Static constructors in circularly imported modules - again

2010-05-27 Thread Michel Fortin
On 2010-05-27 09:57:30 -0400, Max Samukha spam...@d-coding.com said: We cannot impose on the user of Q_OBJECT the requirement that a and b should not be circularly imported or that he has to manually call an initialization function etc. Just a small note... In the D/Objective-C bridge, I've

Re: Static constructors in circularly imported modules - again

2010-05-27 Thread Max Samukha
On 27.05.2010 18:38, Michel Fortin wrote: But it isn't thread-safe, and I expect it would be a pain to make lazy initialization thread-safe, although I haven't tried yet. That has been the very point of this thread (no pun). In my other post I supplied a hack that uses two variables, shared