Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114154
MIME-Version: 1.0
References: <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <d41joRZrrg_u8KP7Av8ivR8TTMjiEyWOVewNRdBKrSjTHtGcqU_5ngObo92bD0Gkl-hbDC4k8n-KxwS1Xnve6GxnPCBvQ1kK9CDoh5CP690=@protonmail.com>
In-Reply-To: <d41joRZrrg_u8KP7Av8ivR8TTMjiEyWOVewNRdBKrSjTHtGcqU_5ngObo92bD0Gkl-hbDC4k8n-KxwS1Xnve6GxnPCBvQ1kK9CDoh5CP690=@protonmail.com>
Date: Sun, 25 Apr 2021 18:58:48 +0200
Message-ID: <CABdc3Wr+xQxBLhPafBsPa9xJqhhLOat8d3_i4jDeQX3_QRB9SA@mail.gmail.com>
To: Saif Eddin Gmati <azjezz@protonmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000003d22905c0cef25e"
Subject: Re: [PHP-DEV] Re: [RFC][Draft] Sealed Classes
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--00000000000003d22905c0cef25e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Saif

sob., 24 kwi 2021, 13:00 u=C5=BCytkownik Saif Eddin Gmati <azjezz@protonmai=
l.com>
napisa=C5=82:

> A major behavior i wanted to discuss is how should sealed interfaces work=
,
> and specially around `Throwable` which is currently sealed to only `Error=
`
> and `Exception`, but allows other interfaces to extend it, and other
> classes to implement it as long as they extend `Error` or `Exception` ( o=
r
> another class that does so ).
>
> As per the current proposal, if `Throwable` is to be declared `sealed`,
> permitting only `Error` and `Exception`, it won't be possible to extend i=
t,
> resulting in a major BC-break, considering that too many libraries extend
> this interface in their own `ExceptionInterface`.
>
> To work around this, there's two solution:
>
> 1. don't declare `Throwable` sealed and keep it as a special case.
> 2. interfaces declared sealed, can be extended by other interfaces,
> however, classes that implement either the sealed interface directly, or
> via another interface, have to extend one of the classes the sealed
> interface permits.
>
> The second solution will allow declaring `Throwable` sealed, and would
> bring complete consistency between internally sealed symbols, and user
> land, without any BC breaks, and IMHO, it doesn't hurt as at the end, no
> one will be able to implement `Throwable` without extending the permitted
> classes.
>

I like the idea of sealed class along with proposed keywords which are
similar to already existing in other languages like Java.

Personally I'd go with the second option.

Speaking of Attributes I prefer not to use an Attribute for any particular
language feature which expects input arguments to be a valid class or
interface name for two reasons: first because there is no effective way to
restrict input string to be a valid class or interface name and second that
it'd require passing strings which means in most cases passing class or
interface name with magic ::class constant read.

Cheers,
Micha=C5=82 Marcin Brzuchalski

--00000000000003d22905c0cef25e--