Re: [PHP-DEV] Re: [RFC][Draft] Sealed Classes
Hello Saif sob., 24 kwi 2021, 13:00 użytkownik Saif Eddin Gmati napisał: > 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. > 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ł Marcin Brzuchalski
Re: [PHP-DEV] Re: [RFC][Draft] Sealed Classes
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 > 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
[PHP-DEV] Re: [RFC][Draft] Sealed Classes
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 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. signature.asc Description: OpenPGP digital signature
