Parallel execution of unittests

[Jonathan M Davis via Digitalmars-d]

On Mon, 05 May 2014 10:00:54 +0000
bearophile via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> Walter Bright:
>
> > D has so many language features, we need a higher bar for
> > adding new ones, especially ones that can be done
> > straightforwardly with existing features.
>
> If I am not wrong, all this is needed here is a boolean
> compile-time flag, like "__is_main_module". I think this is a
> small enough feature and gives enough back that saves time, to
> deserve to be a built-in feature. I have needed this for four or
> five years and the need/desire isn't going away.

As far as I can tell, adding a feature wouldn't add much over simply using
a version block for defining your demos. Just because something is done in
python does not mean that it is appropriate for D or that it requires adding
features to D in order to support it.

Though I confess that I'm biased against it, because not only have I never
needed the feature that you're looking for, but I'd actually consider it bad
practice to organize code that way. It makes no sense to me to make it so that
any arbitrary module can be the main module for the program. Such code should
be kept separate IMHO. And I suspect that most folks who either haven't done
much with python and/or who don't particularly like python would agree with
me. Maybe even many of those who use python would; I don't know.

Regardless, I'd strongly argue that this is a case where using user-defined
versions is the obvious answer. It may not give you what you want, but it
gives you want you need in order to make it so that a module has a main that's
compiled in only when you want it to be. And D is already quite complicated.
New features need to pass a high bar, and adding a feature just so that
something is built-in rather than using an existing feature which solves the
problem fairly simply definitely does not pass that bar IMHO.

I'm completely with Walter on this one.

- Jonathan M Davis