ModuleInfo, factories, and unittesting

rikki cattermole via Digitalmars-d digitalmars-d at puremagic.com
Sun Dec 18 14:55:30 PST 2016


On 19/12/2016 5:53 AM, 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).
>
> Until then, a very nice step forward is to NOT generate ModuleInfo if a
> module introduces no class.
>
> For unittests, I figure things like static introspection should make it
> easier to enumerate and run unittests without a need for ModuleInfo.
>
> What other issues/opportunities do you see related to ModuleInfo?
>
>
> Thanks,
>
> Andrei

I've been toying with the idea of completely overhauling TypeInfo.

Here is the gist of what I want:

- -typeinfo=low/low-min/normal/high/none
   None is pretty much -betterC
   Low would be unittests + module constructors
   Low-min would be like low but with only the fields that is needed
   Normal is what we have now more or less
   High of course includes all the goodies like class fields and methods 
reflection
- Full class + struct + union symbol reflection, so fields uda's ext.

My feeling is D really is two different languages.
An application one and a system one.
The difference isn't much. It really comes down to how hooked into 
druntime it is and so TypeInfo.
 From there we just need to remove all language features that require 
druntime or allow a way to you know, clear deallocation path.


More information about the Digitalmars-d mailing list