personally I'm okay with using an attribute, but using a keyword for type system related features seems like a better fit.
I have added it to the alternative syntax list, which would have a separate vote. https://wiki.php.net/rfc/sealed_classes#syntax ---- On Sat, 24 Apr 2021 16:24:03 +0100 Matthew Brown <matthewmatt...@gmail.com> wrote ---- > On Apr 24, 2021, at 10:43 AM, Levi Morrison via internals > <mailto:internals@lists.php.net> wrote: > > On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei > <mailto:kont...@beberlei.de> wrote: >> >>> On Sat, Apr 24, 2021 at 2:56 PM Pierre <mailto:pierre-...@processus.org> >>> wrote: >>> >>> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit : >>>> 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. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Yeah I second this — I think an attribute might be more appropriate here, and I obviously didn’t feel that way about the “never” RFC. One big benefit of a keyword over an equivalent attribute is that when you see `#[Sealed(...)]` you have to check use statements above to ensure it refers to the actual ‘Sealed’ attribute. What if PHP reserved double-underscore-prefixed attributes for engine use (and treated them as fully-qualified)? Hack does this currently, so you always know what a `<<__Sealed(Foo::class, Bar::class)>>` attribute will do, regardless of use statements. Best wishes, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
