Re: [RFC] [VOTE] Sealed Classes

> > to me this closes extensibility in a hard way. > > This is not necessarily true, we have final in PHP which does > exactly > that, but sealed can still allow for extensibility, just from a > different > point, e.g: > final has the same issue to me: it's a feature of the language that would be better enforced by a static analyzer instead of a runtime check. This would work for me: #[Sealed(A::class, B::class, ...)] interface Foo {...} Then, nothing in php-core but a rule in SA tools to check that the semantics of the attribute are respected (or a custom exception to the rule when a user really wants to ignore the attribute for a specific class, being on their own then). Note that for final this is already common practice - using the @final annotation to express the intent that a class is final but still allow e.g. to generate a lazy proxy or a mock class (or any other need authors cannot anticipate). > Considering the > Option/Some/None > example above, given Option, now > you are sure that it's either an instance of Some or > None, where > previously, a third type could exist. > > Authors previously got around this issue by adding methods on > Option > such as isSome()/UÐ9AÁ? > 8Ä0 Ü_ÍisNone()/isSuccess()/isFailure() > .. etc > Or "instanceof Option|Some|None", which achieves something very similar to me. This relates to the paragraph about composite types in the RFC: most of the problems you describe for them can be solved in practice by introducing an abstract (@internal) class. Please note that I'm making these criticisms in a constructive mindset. I do appreciate that there is an RFC about sealed classes and that we can discuss if and how we want them in PHP. Right now, I'm not convinced we should add them and I'm trying to articulate why, that's all :) Nicolas