On 2012-11-29 19:17, deadalnix wrote:
That is understood, but Let me explain how I see things.
We are here adding yet a new feature, however small. Nothing stabilize
when adding new feature all the time.
The annoyance exist, is real, but is not THAT bad, and 'm pretty sure
the proposed solution is likely to backfire. Firstly because a module
can have several constructors, and more can be added by mixins. Ensuring
that constructor A will not create dependancy cycle error may silently
break other constructor of the module.
Considering the problem static constructor solve, I'd be happy to see
some think out of the box. The way things work here may be broken. Many
people consider that D runtime should evolve in a way that promote
fibers and map them over system threads (this have many benefit : the
program adapt autmatically to the provided hardware, yields can be
introduced directly into the runtime or some libraries to hide IO
latencies, and many other things), and static constructor/variables
really get into the way (you would have to run all static constructors
each time you start a new fiber or reset one to reuse it).
I really wish we can focus on figuring out the uses cases we have for
static constructor and start the reflection from theses sues case and
not from the feature itself.
BTW, how does Java handle this? And C# if it has something similar.
--
/Jacob Carlborg
