On Fri, May 22, 2020 at 1:08 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei <kont...@beberlei.de> > wrote: > >> Hi everyone, >> >> the Attributes RFC was rather large already, so a few things were left >> open >> or discussions during the vote have made us rethink a things. >> >> https://wiki.php.net/rfc/attribute_amendments >> >> These points are handled by the Amendments RFC to Attributes: >> >> 1. Proposing to add a grouped syntax <<Attr1, Attr2> > > 2. Rename PhpAttribute to Attribute in global namespace (independent of the >> namespace RFC) >> > > As was mentioned in one of the previous discussions, we expect that PHP is > going to ship more language-provided attributes in the future. With this > proposal we have the "Attribute" attribute, but I expect we'll at least > have "Deprecated" as well, and probably also something along the lines of > "Jit" or "NoJit". While I'm happy with "Attribute" living in the global > namespace, I don't really think we'd want to introduce "Jit" as a class in > the global namespace. The name is simply to generic and does not indicate > that this is part of the attribute system. We'd be forced to go with things > like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to > me, as we're just reinventing namespaces to avoid using them... > > As such, I would suggest to introduce a common namespace for all > attributes provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate question). > Deprecated would be an "engine level" feature, but Opcache is an extension, so it can have its own namespace "Opcache\Jit". The namespace RFC goes that far mentioning only " core symbols which cannot be unbundled" should go into a PHP namespace, which would exclude Opcache (and its "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core So for me that is not necessarily an argument against Attribute in global NS, because Jit would live in Opcache\. > > Nikita > > 3. Add validation of attribute class targets, which internal attributes can >> do, but userland can't >> 4. Specification if an attribute is repeatable or not on the same >> declaration and fail otherwise. >> >> Each of them is a rather small issue, so I hope its ok to aggregate all >> four of them in a single RFC. Please let me know if it's not. >> >> greetings >> Benjamin >> >
