Walter Bright wrote:
Jarrett Billingsley wrote:
On Sun, May 31, 2009 at 4:39 PM, Walter Bright
<newshou...@digitalmars.com> wrote:
The solution is relatively robust and straightforward. Create a third
module, AB. Module A and module B both import AB. Put the static
constructors for both A and B in module AB. The order of initialization
problem is robustly solved, and all the interdependencies of
initialization
of A and B are explicitly laid out in AB.
If I might speak from personal experience, what usually ends up
happening instead is that A and B get merged into a single module.
This happens enough times, and you have half your code in one file.
What is wrong with the approach I outlined? I use it, it works fine.
1. Requires more code
2. Requires additional modules (!)
(as a consequence to 1+2, code is a lot less clearer to read)
3. When you want template mixins to contain a static this, your approach
doesn't really work at all. The template mixin obviously can't generate
a new module to move the static ctor there. As an example for real life
usage, look at BCS's serialization code. (See his thread on
d.D.announce, code link is on his blog post.) He uses a template mixin
containing a static ctor, to make a class "known" to the serialization
system. Using a template mixin with static ctor is a nice way to hide
that mechanism from the user, but it disallows cyclic module
dependencies. I claim that many users, who try to substitute the lacking
RTTI with a custom mechanism, will hit the same problem.
