Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117355
MIME-Version: 1.0
References: <QHsa8Y5m94yZnEjyPcsmW3_G5d5GRZ3yRDFECWeUSgZ-uEb4almbDLic4beARbjYUUqCORy15oI1RQp4ePyE6H3J4t4Jqd9XtbSg2FKC0Dg=@protonmail.com>
 <CAOWwgpmzbA5F084kxGQ5v6JSuD_RMQMy9+kPgTLKm_TPc9vRqA@mail.gmail.com>
In-Reply-To: <CAOWwgpmzbA5F084kxGQ5v6JSuD_RMQMy9+kPgTLKm_TPc9vRqA@mail.gmail.com>
Date: Thu, 17 Mar 2022 15:01:57 +0100
Message-ID: <CABdc3WouA+D5amGYMwRvr+3UFd=9-ebdd0pcBfjbG=ymHg87vQ@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Saif Eddin Gmati <azjezz@protonmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cffeb405da6a79e1"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Sealed Classes
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000cffeb405da6a79e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Nocolas,

czw., 17 mar 2022 o 11:38 Nicolas Grekas <nicolas.grekas+php@gmail.com>
napisa=C5=82(a):

> Le jeu. 17 mars 2022 =C3=A0 04:54, Saif Eddin Gmati <azjezz@protonmail.co=
m> a
> =C3=A9crit :
>
> > Hello Internals,
> >
> > As per my last email in the previous thread, i have started the vote fo=
r
> > 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 kno=
w
> 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=C5=82 Marcin Brzuchalski

--000000000000cffeb405da6a79e1--