XE7 System.Threading – sealed classes?
What normally motivates sealing?
Performance? Fragile internal structures? Complex dependencies?
XE7 System.Threading – sealed classes?
Published
15 thoughts on “XE7 System.Threading – sealed classes?”
You must log in to post a comment.
I’m curios too…
I’m voting for pure perfection.
Makes them a whole lot less interesting imho… especially since they are missing features like cancellation tokens, inter-thread messaging etc.
From the C# docs
To determine whether to seal a class, method, or property, you should generally consider the following two points:
– The potential benefits that deriving classes might gain through the ability to customize your class.
– The potential that deriving classes could modify your classes in such a way that they would no longer work correctly or as expected.
Another interesting, but poorly documented tidbit: http://docwiki.embarcadero.com/RADStudio/XE7/en/E2390_Class_must_be_sealed_to_call_a_private_constructor_without_a_type_qualifier_(Delphi)
As possible reason – to nobody challenge awesomeness of their code 🙂
Just look at the code and you know.
Fear.
Performance: only if you use it to replace “is” checks with “ClassType=” (has it’s uses, quite corner case)
Also it can make sense for future proofing, if you know where you want the structure to go, but haven’t had time to implement it yet, and don’t want people to build upon your structures in ways that would prevent those structures to evolve (because people bitch, rightfully, at breaking changes).
I’m going with “to encourage people to use OmniThread library” 🙂
Eric Grange – Future proofing for work in progress makes sense. Still, a bit annoying.
Lars Fosdal yes, but the alternative is either bloating the class with some “SomeMethod2” or “SomeMethodEx” once you realize people overrode the “SomeMethod” to do things they should not have, or just abandoning the old structure and starting anew… which is just as annoying 🙂
Moz Le Omni is excellent, but not cross platform…. Yet
A few possible motivations for sealing a class come to mind:
1. If you design an immutable class any programmer that comes after you can write a descendent that ignores that immutability, breaking any assumptions you may have made in your design.
2. Sealing a class can be a heavy handed way to enforce composition over inheritance.
Kenneth Cochran I wish the language would allow for enforced immutability.