Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114123
MIME-Version: 1.0
References: <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org> <CAEPJdun9jhST-L7CPHSJZtg3Q9rFEy7aFXU0Y7NCv_cPMHrVEg@mail.gmail.com>
In-Reply-To: <CAEPJdun9jhST-L7CPHSJZtg3Q9rFEy7aFXU0Y7NCv_cPMHrVEg@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Sat, 24 Apr 2021 08:43:12 -0600
Message-ID: <CAAKU0umEdiub7rBvPpW9nU7EGBnptLzO7sGL+aKSxsEsCHEf8w@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Pierre <pierre-php@processus.org>, Saif Eddin Gmati <azjezz@protonmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: internals@lists.php.net ("Levi Morrison via internals")

On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei <kontakt@beberlei.de> wrot=
e:
>
> On Sat, Apr 24, 2021 at 2:56 PM Pierre <pierre-php@processus.org> wrote:
>
> > Le 24/04/2021 =C3=A0 12:55, Saif Eddin Gmati a =C3=A9crit :
> > > Hello Internals,
> > >
> > > I'm sending this email to open discussion about sealed classes,
> > > interfaces, and traits feature for PHP 8.1.
> > >
> > > I have create a Draft RFC here:
> > > https://wiki.php.net/rfc/sealed_classes
> > > <https://wiki.php.net/rfc/sealed_classes>
> > >
> > > A major concern for few people have been the syntax, in which it
> > > introduces 2 new keywords into the languages, therefor, i have added =
a
> > > section about alternative syntax which could be used to avoid this
> > > problem.
> > >
> > > Regards,
> > >
> > > Saif.
> >
> > Hello,
> >
> > And why not using an attribute, such as in HackLang ?
> >
>
> +1 on this, I said the same on the "never/noreturn" RFC. There is a much
> less invasive way to add new keywords/flags to functions by using
> attributes.
>
> Imho this decouples new features from the language and reduces the "risk"
> of adding them to the language. That should increase the likeliness of it
> getting accepted in my opinion.

I think an attribute may be appropriate here because sealed types act
like normal types, except we restrict who can extend them.
Additionally, we have to provide data about which types can extend the
sealed type, so it's not just a simple on/off type behavioral switch
(which I think is an antipattern for attributes based on my experience
in other languages that have them).

This is different from a return type `never`. A function which never
returns cannot meaningfully have any return type at all -- using
`void` or some other type with an attribute would be a lie.
Additionally, there isn't any meta-data to associate with the `never`.
I hope this comment doesn't digress into a conversation about `never`;
that isn't my point. I'm trying to provide more justification about
when I think attributes are appropriate, because I think they may be
appropriate here and I think it's useful to show how `never` is
different.