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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
