On Thu, May 28, 2020 at 12:05 AM Benas IML <benas.molis....@gmail.com> wrote:
> It seems that the RFC was updated to use the `Attributes` namespace. I > think this is a bad idea since we're reserving a generic namespace that we > haven't even "soft" reserved. Also, the loss of fallback to global > namespace is a turning point for me. > > Generally, I think we should instead do something like Rowan said: use > namespaced classes only for implementations (e.g. `\Attribute` but > `\PHP\Deprecated`). > I agree on sentiment, but the PHP namespace vote is failing right now, so that makes this plan just a rehashing of the existing, failing vote. The likelihood of a class Attributes\Attribute or Attributes\Deprecated existing in any code out there is much much lower, than the classes Attribute and Deprecated existing in the global namespace. The "PHP\" namespace would imply some sort of claim of the project, which the failing namespace vote shows does not exist. The way attributes map to classes, suffixes/prefixes make them strange to look at, so for future non-breaks with userland code it will be safer to put them off to a new namespace and this potentially increases the user perception. If this vote fails, this implicitly means that all future internal attributes will probably go into the global namespace. > > Best regards, > Benas > > On Wed, May 20, 2020, 8: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) >> 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 >> >
