Re: [RFC] [VOTE] Sealed Classes
| From: | Michał Marcin Brzuchalski | Date: | Thu, 17 Mar 2022 14:01:57 +0000 |
| Subject: | Re: [RFC] [VOTE] Sealed Classes | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117355@lists.php.net to get a copy of this message | ||
Hi Nocolas,
czw., 17 mar 2022 o 11:38 Nicolas Grekas <nicolas.grekas+php@gmail.com>
napisał(a):
> Le jeu. 17 mars 2022 à 04:54, Saif Eddin Gmati <azjezz@protonmail.com> a
> écrit :
>
> > Hello Internals,
> >
> > As per my last email in the previous thread, i have started the vote for
> > sealed classes feature.
> >
> > The vote will run for 2 weeks until March 31st 2022.
> >
> > Discussion: https://externals.io/message/117173
> >
> > Draft Discussion: https://externals.io/message/114116
> >
> > RFC: https://wiki.php.net/rfc/sealed_classes
> >
>
> Hello Saif,
>
> Thanks for the RFC.
>
> I voted "no" because to me this closes extensibility in a hard way. If
> users are fine ignoring an "@internal" annotation, or using reflection to
> access private symbols, then I think that's fine: their problem; they know
> why they need to do so - not authors. Allowing authors to forcibly remove
> that capability from users is going too deep into removing power from
> users.
>
> Said another way, I don't think this solves any problem that authors face
> in practice. As such I don't think this is worth the added language
> complexity + removal of power.
>
I'd say this is a very weak argument, we do the same with the final on
class, method, property level already.
But well, it's your vote.
Cheers,
Michał Marcin Brzuchalski