Program size, linking matter, and static this()
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Fri Dec 16 11:48:33 PST 2011
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
More information about the Digitalmars-d
mailing list