On Sat, Apr 24, 2021, at 6:00 AM, Saif Eddin Gmati wrote: > 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` ( or 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 > it, 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. > > Note: with the second solution, if an interface is sealed and permits > only 2 classes which are final, and you extend that interface into > another, there's no way you can actually implement your new interface, > and i will be as if you just declared a final interface. > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, April 24, 2021 11:55 AM, Saif Eddin Gmati > <azj...@protonmail.com> wrote: > > > 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 > > > > 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.
1) I am generally supportive of this concept. 2) For exceptions, I'm honestly fine with Throwable just being weird. It already is, so letting it stay weird doesn't hurt anything. 3) The syntax examples mention traits, but nothing else in the spec talks about traits. What does sealed mean on a trait? I assume "can only be 'use'd by these classes", but that should be explicit. 4) I'm on team Attributes for the syntax, for two main reasons. One, it eliminates the need for a new keyword entirely. It would only require defining a new built-in class, and that class could be namespaced (per the likely-to-pass namespace policy) so that it is unlikely to conflict with anything at all. Two, I find it visually better as it it is not part of the type system per se, but a sort of meta-type system. Which is exactly where Attributes fit. (Basically what Levi said.) 5) If this passes, then combined with Nikita's "new in intializiers" RFC (https://wiki.php.net/rfc/new_in_initializers) it would effectively give us ADTs/Union Types by a different syntax. One could argue which syntax is better or more convenient (I'm not sure which I favor myself), but I'm just calling out that this would give us effectively the same result in terms of capability. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
