Defining some stuff for each class in turn

[Christopher Wright]

Andrei Alexandrescu wrote:
> Christopher Wright wrote:
>> Andrei Alexandrescu wrote:
>>> I am becoming increasingly aware that we need to provide some means 
>>> to define certain members (data and functions) for each class as if 
>>> they were pasted there.
>>
>> Most of the examples given would be well served by decent builtin 
>> reflection. Walter thinks reflection is too expensive to be active by 
>> default. Find a cheaper way to provide runtime reflection. It's not as 
>> sexy as using templates, but it's DRY and easier to use. Slower, but 
>> you don't pay the cost of reflection multiple times if you have 
>> multiple libraries requiring reflection.
> 
> What cheaper way would be than allowing a base class to prescribe 
> reflection for its hierarchy? Where do templates even enter the mix? 
> What's slower and why? Why do reflection as a language feature 
> (increases base language size, buggy, rigid) instead of allowing it as a 
> library if we so can? I'm totally against that.
> 
> Andrei

Once you get two or three libraries using reflection, it's cheaper to 
have the language provide it than to have separate, incompatible 
reflection systems.

It doesn't matter whether the language provides reflection or the 
standard library. (The only way for me to tell is whether I'm importing 
from core or from std.) Either way, it should be standardized and easy 
to opt in or out (depending on the default), and there should be no way 
or no cost for opting in twice.

You have to use templates to get reflection info, currently. Unless CTFE 
has gotten a lot better, in which case it's effectively the same as 
using templates, but with a bit less executable bloat.

Template-based solutions can be faster than reflection-based solutions 
because you can access fields and methods directly. But runtime 
reflection doesn't disallow templates.