Entry (main) method inside a class?

[Frits van Bommel]

Thomas Kuehne wrote:
> Frits van Bommel schrieb am 2007-03-16:
>> Though I could see uses for this, like to run unittests (similarly to 
>> what running Python modules "stand-alone" often does).
>> D has gone another way there though, using explicit unittest {} blocks. 
>> Unfortunately, there is currently no way to run these separately (esp. 
>> right after compilation) that I know of.
> 
> Flectioned's unittest walker does exactly that:
> 
> dmd -unittest -g -c <your source>
> dmd flectioned.d unittest_walker.d -ofwhatever <your objects>
> ./whatever
> 
> http://flectioned.kuehne.cn

Interesting, I wasn't aware of that.
Looking at the source though, is there any particular reason the code is 
in a static this() instead of in the empty void main() at the end?
Shouldn't unit tests be performed after all static constructors have 
been completed, so that the modules being tested have been initialized?
That, to me, indicates that the code should be in main().
Though with the recommended lines the code linked from .ctors probably 
links the ModuleInfo in the right order (from what I remember, it links 
each module at the head of the linked list, reversing the order), that 
doesn't look very robust.
And why the empty main()? Is that to make sure that one gets linked 
instead of any main() provided in the other object files?
And a static constructor that shuts down the gc and ends the program 
also just seems a bit fishy :), though in this case (given that the code 
is in a static this()) it seems to be what you want to do.

But what exactly is the use case here? To just run the unit tests and 
avoid running main()?
Wouldn't that be more easily accomplished by just letting the unit tests 
run "manually" and providing an empty main()?
Of course, that wouldn't provide as nice an example of flectioned use :P .