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

Paul Ishenin ip at kmiac.ru
Mon Oct 19 06:43:13 CEST 2009


Marco van de Voort wrote:

> For delphi compatibility we only need to skip it. I agree mostly with Jonas
> here, I think this is one of those access control things added by popular
> demand (because language xxx has it).

Maybe in open source world sealed classes has small meaning since you 
can always change the code. But even then they have a warning function.

But they do their security role very good when you distribute your code 
in the binray form.

Except the security role sealed and abstract classes have their 
important oop meaning. Look at the next "phones example":

TBasicPhone = class abstract
TCellularPhone = class(TBasicPhone)
TSatelitePhone = class(TBasicPhone)
TDialPhone = class(TBasicPhone)
...
TNokiaPhone = class(TCellularPhone)
TNokia37xxPhone = class(TNokiaPhone)
TNokia3720Phone = class sealed(TNokia37xxPhone)

TBasicPhone is ofcource an abstract class. It can have some basic fields 
like color, weight, dimensions, ...
TNokia3720Phone is a final product which can't have any further 
derivations. It is logically to mark this class as sealed to prevent 
ocasional errors.

After all, nobody ask to use sealed/abstract classes as much as 
possible. If you don't like them - just don't use them. Why to limit 
other developers?

Best regards,
Paul IShenin.




More information about the fpc-devel mailing list