ModuleInfo, factories, and unittesting

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/16 6:48 PM, Nicholas Wilson wrote:
> On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote:
>> Compulsive ModuleInfo generation seems to be a drag. I'm not very
>> familiar with the particulars but my understanding is ModuleInfo is
>> needed for (a) Object.factory and (b) finding and running unittests.
>>
>> Walter and I think Object.factory was a mistake and we'd like to make
>> it opt-in long term (either by means of a build flag or a class
>> attribute).
>>
>
> Don't forget that typeinfos are classes too, which makes the class
> attribute approach less attractive.
>
>> Until then, a very nice step forward is to NOT generate ModuleInfo if
>> a module introduces no class.
>>
>
> Module (static) ctors & dtors need MI.

Cool cool cool. Thanks.

>> For unittests, I figure things like static introspection should make
>> it easier to enumerate and run unittests without a need for ModuleInfo.
>>
>
> We have __traits(getUnitTests,...) but the way to do DIY unittests is
> foreach(m; ModuleInfo)
>     foreach(test; __traits(getUnitTests,m)
>         test();

Noice. Wait, the top foreach iterates what?

>> What other issues/opportunities do you see related to ModuleInfo?
>>
>
> AFAIK a module info is basically
>
> struct ModuleInfo
> {
>     alias  F = void function();
>
>     ModuleInfo* parent;
>     string name; // may be static char array
>     F s_ctor; // Static constructor
>     F s_dtor;
>     F ctor;    // Thread local constructor
>     F dtor;
>     F unittester; //may be an array for each block
>     void function(Object)[string] factory_mapping; //Foward to argless
> ctor, not sure what mapping is actually used.
> }
>
> If we optionally remove Object.factory, and move the unittests elsewhere
> (where to?) we are left with the ctors and dtors. If we store these as
> SoA

SoA = ?


Andrei