On Tuesday, March 08, 2011 07:40:08 spir wrote:
> On 03/08/2011 03:48 PM, Jonathan M Davis wrote:
> > I really don't understand your problem with module constructors. They're
> > fantastic.
>
> I may be wrong, but I think this point of view is a "where I can from"
> statement. C's char* are fantastic when you have never used a PL with
> builtin strings. There are languages in which you don't need to list twice
> everything just to have them available at import time.
>
> // data definition
> X foo;
> Y bar;
> Z baz;
> ...
> static this {
> foo = ...;
> bar = ...;
> baz = ...;
> ...
> }
In one case, you're declaring a variable. In another, you're giving it a value.
They're two _very_ different things. In one case, you're telling the compiler
that a particular variable exists. In the other, you're giving it a value.
Generally, it is ideal to give a variable its initial value (and final value if
it's not mutable) when you declare it, and there's no question that CTFE is
currently not as good as we'd like in that regard. However, there are plenty of
cases where it makes no sense to give a variable its initial value at compile
time. So, given that D requires that _all_ module variables, class/struct
variables, and member variables which are directly initialized have that value
known at compile time, you have to do it separately to do it runtime. Also,
there are plenty of cases where there are dependcies between variables such
that
you need to actually give them values within a function rather than statically.
Constructors do a beautiful job of dealing with this problem.
The main alternative is to allow you to set module, class/struct, and member
variables directly at runtime. Languages such as C++ and Java do this, and it
causes a host of problems. The order of initialization isn't necessarily
defined.
It's possible to end up using variables before they're actually initialized.
Compilation is slower because of all of the interdependencies, whereas in D
it's
possible to parallelize a lot of what the compiler does with declarations,
because they're not interdependent like they are in C++ or Java. Not to
mention,
if you want to be able to initialize them in a manner which requires you to
essentially have a function rather than set them directly, then you _need_
something like a constructor to initialize them. Also, you don't get compile
time evaluation of variables in languages like C/C++ and Java like you do in D,
so _every_ variable is initialized at runtime. The occasional irritation with
the current implementation problems of CTFE is _well_ worth the gain in compile
time evaluation.
D uses a model similar to C/C++ and Java, but it improves on it _considerably_
by doing things the way it does. The order of initialization in D is _well-
defined_ and not bug-prone. It also lends itself to efficient compilation.
Granted,
until CTFE is able to do anything in SafeD (as its intended to do eventually),
there are going to be irritating restrictions with regards to what we can and
can't initialize directly using CTFE, but that's an implementation detail which
will improve. D's design in this regard is excellent.
- Jonathan M Davis
