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.
