Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111231 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 16423 invoked from network); 28 Jul 2020 20:42:30 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 28 Jul 2020 20:42:30 -0000 To: internals@lists.php.net References: Date: Tue, 28 Jul 2020 20:38:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 87.81.129.66 Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change From: marandall@php.net (Mark Randall) Message-ID: 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. 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)] 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]) 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)] 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. -- Mark Randall