[fpc-devel] class abstract, class sealed implementation. please review.

[Jonas Maebe]

Florian Klaempfl wrote on Sun, 18 Oct 2009:

> Jonas Maebe schrieb:
>> Florian Klaempfl wrote on Sat, 17 Oct 2009:
>>
>>> Graeme Geldenhuys schrieb:
>>>> Would you mind explaining this - I never saw the benefit of a sealed
>>>> class.
>>>
>>>> From a compiler developers point of view, it makes optimization easier
>>> under certain cases (e.g. virtual method calls).
>>
>> FPC can already do this automatically for all classes in the entire
>> program with whole-program optimization. You don't need sealed classes
>> for this (they might slightly improve those optimizations,

I made a mistake here: they can't improve it. Since such a class won't  
be derived from even without the "sealed" specifier, the compiler can  
perform all those optimizations automatically already.

>> but I doubt
>> it will be noticeable in real life -- even doing it for an entire
>> program using WPO generally has no noticeable effects on speed, and only
>> marginal effects on code size).
>
> True. But sealed requires no recompilations to do the optimization, so
> it works always.

Declaring a class as "sealed" for optimization purposes is a  
micro-optimization that pollutes the source code. In that case, you'll  
probably have to revert that change again later if you or someone else  
does have to inherit from the class after all. It may also force  
people into using delegation rather than inheritance, and this in turn  
can cause problems if the sealed class is "unsealed" later on and new  
descendants are created after all (e.g., because they directly created  
a delegate of the "sealed" type since it couldn't be inherited from  
anyway).

Manually doing things that can be automated is almost never a good idea.


Jonas

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.