Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114205
MIME-Version: 1.0
References: <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <CAJpLVh2UybGgAqhfAGQ=kKQ-qvmG68HWKaUJXOwPv7DgEbAdKw@mail.gmail.com>
 <179049b1475.11134368b213512.254739612773841999@void.tn> <CAJpLVh0pz_WopKza=XXqPrvS4bQZhWom1FQ6QLW-fbC-8JHkrA@mail.gmail.com>
 <CADyq6sLtgNkyM-qQcwRY8mMOxnkrz_9qeG6XK2uDBqsh=smMtg@mail.gmail.com>
 <CAJpLVh3C63FTUzWusVOp5JOGpuKbOYi0WovYvNFv20npNJFh3g@mail.gmail.com>
 <b4276d92-4856-4222-8c34-55b1422030c5@www.fastmail.com> <EA268E52-2954-40DE-B3CC-D447A4983887@cschneid.com>
 <CAC5V6gghaZv=MCQz+FWNDAMUj2KorjvL_tNO+DNAPT0ioycpSA@mail.gmail.com> <CA+p1FabuUDUzMkEhwyy0BJVd71N=6ubn5pEJNh8VkE8D9rJhow@mail.gmail.com>
In-Reply-To: <CA+p1FabuUDUzMkEhwyy0BJVd71N=6ubn5pEJNh8VkE8D9rJhow@mail.gmail.com>
Date: Tue, 27 Apr 2021 12:57:32 -0400
Message-ID: <CAPKYkKyqrPsTVHD9k3Axq30HALeBBJjwaMzkWzbXX4fX6BG-Yg@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: Guilliam Xavier <guilliam.xavier@gmail.com>, Christian Schneider <cschneid@cschneid.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000025528605c0f72969"
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000025528605c0f72969
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 27, 2021 at 12:47 PM David Gebler <davidgebler@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.xavier@gmail.com>
> wrote:
>
> > Hi,
> >
> > On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider <
> cschneid@cschneid.com
> > >
> > wrote:
> >
> > > Am 25.04.2021 um 05:47 schrieb Larry Garfield <larry@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
chasepeeler@gmail.com

--00000000000025528605c0f72969--