4 ms·
I second removing sealed (and final) from all languages (except maybe for embedded/microcontroller work where implementation details matter). This issue might
by zackmorris 6y ago
I second removing sealed (and final) from all languages (except maybe for embedded/microcontroller work where implementation details matter).
This issue might not seem relevant in your own projects, where maybe you want to seal a class so a junior developer doesn't break something.
But it's disastrous for library and framework development. Here's an open question of mine related to this:
https://stackoverflow.com/questions/65852139/listen-for-changes-to-mesh-class-for-rebuilding-metadata-in-unity https://stackoverflow.com/questions/65852139/listen-for-chan...
In that case, I'm trying to write a script that people can attach to a game object to rebuild metadata after a mesh is changed. I need the metadata for my shader, since it needs info about neighboring vertices, which would only be available in geometry shaders (which have fallen out of fashion since they run at the wrong stage of the rendering pipeline).
That way my shader would "just work" without making the user have to remember to set a flag or send an event when something changes (which is not future-proof).
Normally I would just inherit from the Mesh class, override/extend methods like Mesh.SetVertices(), and then explain how to use my class in the readme. Better yet, I would use something like inversion of control (IOC) to replace the project's global Mesh class with my own (this is how frameworks like Laravel work, or try to work). In fact, there are half a dozen ways of accomplishing this, perhaps more.
But with sealed and final, I'm just done. There is no workaround, by design. Because C# inherited this kind of opinionated thinking (anti-pattern) from Java. And Unity uses C#, so unwittingly fell into this trap since so many of their classes are sealed. Which all reduces languages like C# and Java to being toy languages, at least for someone like me working from first principles under some approximation of computer science.
Maybe I should write to Unity and explain that all of this happened during the very first interesting thing I tried to do. Or maybe we could get rid of this concept altogether and avoid the problem in the first place.
Even the gospel of Martin Fowler tends to agree with my stance on this:
https://martinfowler.com/bliki/Seal.html https://martinfowler.com/bliki/Seal.html
- dominikbucher 6y agoCan't speak for all languages and usecases, but at least in Scala its primary use (afaik) is to enable the compiler to reason about the correctness of an application (i.e., it knows all the possible subclasses of a class and can tell you if you forgot to handle some case). I think this is also useful in other languages if you have some logic somewhere that depends on knowing all possible subclasses of a class (independent of the compiler generating warnings or not).