> 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
Note: i have removed the choice for `#[Sealed(...)]` attribute syntax, while i don't mind it, i don't see a valid point for using attributes, other features ( e.g final classes ) use modifiers, and so should `sealed` as it is more comparable to `final` than other stuff people usually use attributes for ( e.g: #[Assert\Length(min: 2)], #[ORM\Entity], #[ApiResource] .. etc ). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
