static this sucks, we should deprecate it

[Christopher Wright]

grauzone wrote:
>> I had the same problem when writing the D/Objective-C bridge. 
>> Basically, if you ask the Objective-C runtime to instanciate a class 
>> not previously registered, it won't find it. My choice was to require 
>> manual pre-registrations of the classes you want to use, and register 
>> everything that is possible lazily as soon as you use a bridged class.
> 
> Yes, and that "pre-registration" is only there to make the compiler 
> generate the required compile-time reflection code (like with .tupleof 
> or __traits). While compile-time reflection is probably really more 
> flexible than runtime reflection, requiring this kind of "registration" 
> remains a weakness of the compile-time approach.
> 
> Solutions would be to make reflection fully dynamic (as you said) and 
> extend RTTI for that, or to provide better ways to inspect modules as a 
> whole.
> 
> For the latter, maybe __traits should just be able to inspect all 
> members of a module, and to follow imports. Or one could introduce some 
> kind of "module preprocessor", which enables you to execute code for 
> each module at compile time (transparent for the processed module).
> 
> Just by the way, annotations would also be nice. It's annoying to add 
> additional information to members without them. This "additional 
> information" can be stuff like default values, versioning of 
> serializable members, behavior for missing values on deserialization, 
> human readable help text if you want to use reflection to read/write 
> user configuration files...

I've seen four good uses of annotations in the past that could not 
easily be replaced:
- dependency injection configuration
- ORM configuration
- event broker registration (this method should be called on this event)
- test method/class registration

This brings up an issue. Let's say I use static constructors to 
configure a serialization library, then use a static constructor to read 
objects using this serialization library. There's no way to define an 
order in which static constructors should be run within a module, but 
here it makes a huge difference. It would be very convenient to have as 
much of this configuration as possible in a readable format and not 
static constructors.