Re: [RFC][Draft] Sealed Classes

On Sun, Apr 25, 2021, at 3:51 PM, David Gebler wrote: > My argument is not that there aren't legitimate cases where you want to > indicate a class or interface as sealed, nor that developers should not be > empowered to make this indication. Right here is the core point. This is a subjective statement, and one with which I (and apparently many here) disagree. Note that the *exact* same argument could be made for typing parameters. I can document via a docblock that I expect a given parameter to be a string, or a Request object, or whatever. "There is little to no benefit in expressing that through a new language construct rather than through existing constructs and design patterns." Except there very much is a benefit, for making the intent of code clearer and for allowing the engine to syntactically make certain invalid states impossible. Adding more typing power to PHP has been a phenomenal win over the past 15 years precisely because it converts certain bugs and error conditions into fatal errors with no additional work required on the part of the developer. That is a *good thing*. ADTs, sealed classes, enum, and other functionality in that space is a continuation of the same process: Allow developers to use the language syntax to make invalid states impossible to describe, and thus bugs from invalid state go away. Documentation, in whatever form, simply can't do that. It has nothing to do with "inheritance is dangerous." It has to do with accurately and completely describing the problem space. Also, sure, you can fork any library and hack out the parts you don't like. That is true for sealed classes, for enums, for property types, for the entire language. It's also completely 100% irrelevant, precisely because you're modifying upstream code, so all bets are off anyway. --Larry Garfield