On Tue, July 28, 2020 at 2:38 PM Mark Randall <marand...@php.net> wrote:
> On 28/07/2020 18:57, Theodore Brown wrote: > >> Having a closing ] makes it easier to extend Attributes with more syntax > > > > This might be a good argument if there were actually a need to extend > > attributes with more syntax. What other languages have found a need for > > this? Even Rust doesn't allow additional syntax inside the brackets. > > Just because they haven't, does not mean we won't. Unless there's a good > reason to do otherwise, we should provide for future flexibility where > possible. > > I previously provided examples of ways in which we might want to extend > the syntax. Hi Mark, I appreciate the examples. I think there are good reasons not to implement these kind of extensions, at least in this form. I'll reply to each example below. > Most things in PHP allow some level of scope restriction, such as > private or protected. One day we may want to extend annotations to > include such a feature, such as a protected annotation that can only be > accessed by the class itself or its descendants. > > #[protected MyAttribute(xyz)] Given that attributes are metadata, restricting their scope seems rather pointless, and probably would only encourage their (mis)use for things they aren't the right solution for. Isn't the whole point of an attribute to be read by something outside the class? If the metadata is only for the class itself, class constants with appropriate visibility can be used instead. > Attributes are not validated when they are encountered, this may be > something that we wish to allow attributes to opt-in to in future. > > #[checked MyAttribute(xyz]) I hope if we allow opting into such a feature it won't have to be so verbose and won't require making checked a new reserved keyword. I suppose the same thing could be accomplished with a distinct token, for example: @@!MyAttribute(xyz) > In future we might want to offer APIs that return an array of all of the > instances (moving the creation up from newInstance) and then tighten up > the behvaiour for classes which do not exist (because they might belong > to an optional package, such as debugging or code analysis). This might > come in the form of something like: > > #[optional MyAttribute(xyz)] Existing attributes are already optional, though, so it's not clear what value this would add. If we want some attributes to not be optional, we could add a new syntax for checked attributes like the previous example. > Some of these might happen, none of these might happen, something > completely different might happen. > > What is clear is we've got to support Attributes for 20, 30 years, and > we should leave the door open for easier and cleaner syntax additions if > there's no compelling reason not to. I'm not convinced this approach of additional keywords before an attribute is the easiest or cleanest way to implement additions. It seems like it could lead to more BC breaks and unnecessary verbosity if it encourages adding new keywords. And as you point out, whether any such additions happen is completely hypothetical right now. In the present what we do know is that #[] is a bigger BC break than @@, and that other languages haven't had a need for such syntax additions in the many years that attributes have been around. Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
