On 12/16/11 1:23 PM, Steven Schveighoffer wrote:
I disagree with this assessment. It's good to know the cause of the
problem, but let's look at the root issue -- reflection. The only reason
to include class information for classes not being referenced is to be
able to construct/use classes at runtime instead of at compile time. But
if you look at D's runtime reflection capabilities, they are quite poor.
You can only construct a class at runtime if it has a zero-arg constructor.
So essentially, we are paying the penalty of having runtime reflection
in terms of bloat, but get very very little benefit.
I'd almost agree, but the code showed doesn't use Object.factory(). So
that shouldn't be linked in, and shouldn't pull vtables.
I think there are two things that need to be considered:
1. We eventually should have some reasonably complete runtime reflection
capability
2. Runtime reflection and shared libraries go hand-in-hand. With shared
library support, the bloat penalty isn't nearly as significant.
I don't think the right answer is to avoid using features of the
language because the compiler/runtime has some design deficiencies. At
some point these deficiencies will be fixed, and then we are left with a
library that has seemingly odd design choices that we can't change.
Runtime reflection is great, but I think it's a separate issue from
what's discussed here.
Andrei
