Yes I agree Chris, this is the same kind of argument I am making.
> 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."
Yes and no. There is a critical difference between type checking and sealed
- type checking can actually prevent and catch bugs in the form of
objective logical errors (e.g. $total = getSum(1, 2, "not a number"))
before they occur, whereas sealed can only prevent things you did not
intend or foresee, without knowing anything about how I am using some code;
there is no bug or logical error which the use of sealed will prevent *in
and of itself*.
> 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.
This is not runtime benefit, it is runtime overhead. PHP cannot generate a
better opcode sequence for knowing a class is sealed. In terms of
implementation, the only thing it can do is scream "Hey! The author of this
class didn't intend for you to use it this way!" - your IDE can do that
from an attribute.
And although I would say the claim no one will ever have a legitimate &
good reason to extend some class and be able to do so in a way which does
not violate whatever protections against invalid state you had in mind is a
very bold prediction which is rarely borne out by reality - my objection
here is not about people marking classes as sealed, it's that we don't need
a new language construct and keyword to achieve the only benefit it
delivers (declaration of intent to users and IDE). If PHP reasoned about
classes in the same way compiled, statically typed languages do and
therefore derived some tangible compile-time benefit from a sealed
construct, I would be in favour of it.
On Mon, 26 Apr 2021, 08:54 Christian Schneider, <cschn...@cschneid.com>
wrote:
> Am 25.04.2021 um 05:47 schrieb Larry Garfield <la...@garfieldtech.com>:
> > In practice, I think all of the use cases for sealed classes are
> ADT-esque. As I noted before, combining sealed classes with Nikita's
> new-in-expressions RFC would allow for this (also using my short-functions
> RFC for this example, although that's a nice-to-have):
> >
> > sealed class Maybe permits Some, None {
>
> ...
>
> > }
> >
> > final class None extends Maybe {}
>
>
>
> This is exactly the thing I'm worried about.
>
> Say I want to add something like logging to the None type.
> Now your sealed and final classes prevent me from defining MyNone
> extending None even though it would be 100% compatible with None. Just
> because *you* deemed that useless or wrong.
>
> I've encountered situations like this and came to the conclusion that
> while this makes sense for languages like Haskell - where the whole idea is
> to be able to reason about a complex type system - it is an anti-pattern
> for other languages like PHP.
>
> Referring to another post, not yours: People, please don't use Java as a
> reason to add something to PHP, Java is the king of anti-patterns ;-)
>
> - Chris
>
>
