Still, it remains that one could have a legitimate, justifiable reason to
extend Maybe / some other example, which was not foreseen by its author and
is prevented by sealed as a keyword despite the fact this inheritance,
correctly implemented, would not break anything, not define an impossible
state and not violate anything except the library author's own (limited)
imagination of how their code ought to be used.
Note in respect of the point people have raised about attributes and my own
previous comments, I am not advocating any Sealed attribute is added to the
language as a functional change or embedded language by the backdoor, I am
merely saying *you* as some class's author can add an attribute, right now,
to indicate that you consider the class sealed - and an IDE / automated
tooling could understand it and warn a user there is a risk to violating
it.
What's being proposed in the RFC is a functional change to the language
whereby attempting to extend a class designated as sealed to a
non-specified child results in a fatal error.
Now that is not a benefit in itself, it is merely a description of the
proposed change. My question is who or what benefits from this change? And
I look at this way:
1. The language engine doesn't benefit, since unlike some compiled
languages, there is no indication here it will result in improved opcode
sequences.
2. The author of code doesn't benefit, to any extent greater than they
would by using an attribute or other metadata to indicate their intentions,
because if someone else comes along, installs their library and creates
problems for themselves by extending some concrete type in a manner which
was not intended, the author's obligation to them is zero. If improperly
inheriting or otherwise misusing code creates a problem for a consumer,
it's the consumer's mess to sort out.
3. The consumer of code doesn't benefit, because if they didn't intend to
inherit from a sealed, concrete class, it being sealed makes no difference.
But if they did - and had a legitimate reason to do so - they are now
forced to fork, proxy or otherwise work around this artificial restriction
(which they can easily do, by the way, language keyword or none). In any
valid use case, this can distinctly and only be a disadvantage to them.
Someone - Larry I think - said something to the effect of this isn't about
restricting your users as an author from doing something you think they
shouldn't, and that it's about more completely defining problem spaces at
language level. I respectfully am not convinced. When we look at features
like enums and stronger typing, we can see distinct benefits in how as
users of PHP we can model better and write better, more effective and more
efficient code.
But in the case of sealed and the context of PHP, you cannot model your
problem space this way better than you can with an attribute or other means
of annotating metadata. I can certainly agree such metadata is an important
part and valuable tool for improved modeling, but making it a keyword and
throwing a fatal error if your limited intentions (which do not predict all
possible use cases) are violated is merely constraining users from being
able to do something for its own sake. While there is a legitimate argument
that serves to "syntactically make certain invalid states impossible", it
does the same for any valid states you didn't envision.
I'm maybe even inclined to suggest the desire to make a class sealed really
smells like you want to be using abstract classes and/or interfaces.
To the greatest extent which is practical, my preference is to enable other
developers rather than constrain them (subject to the caveat I will not
help them if they do something silly or irresponsible with my code on their
own volition) - I don't believe the "weirdness" exceptions PHP makes
internally for things like Throwable or Traversable are good reasons to
extend this to the language level.
On Tue, 27 Apr 2021, 16:05 Guilliam Xavier, <guilliam.xav...@gmail.com>
wrote:
> Hi,
>
> On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider <cschn...@cschneid.com
> >
> wrote:
>
> > Am 25.04.2021 um 05:47 schrieb Larry Garfield <la...@garfieldtech.com>:
> > ...
> > > 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.
> >
>
> I just want to note that this has nothing to do with Maybe made sealed
> (which seems legit), only with None made final (which... could be debated,
> but unrelated to the RFC at hand).
>
> Regards,
>
> --
> Guilliam Xavier
>
