On Tue, Apr 27, 2021 at 12:47 PM David Gebler <davidgeb...@gmail.com> wrote:
> 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.
>
>
>
I totally agree with everything said above.
I will add that while I don't support the idea of sealed classes in any
way, were it to be implemented, I agree that implementing it via
compiler/engine enforced attributes is not the way to do it, echoing Dan's
reasoning from earlier.
>
> 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
> >
>
--
Chase Peeler
chasepee...@gmail.com
