Program size, linking matter, and static this()

[Jacob Carlborg]

On 2011-12-16 20:48, Andrei Alexandrescu wrote:
> 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.

There are other runtime reflection functionality that can be used.

>> 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.

I don't think it's completely separate. Can the compiler know if runtime 
reflection is used or not?


-- 
/Jacob Carlborg