Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Renaming PhpAttribute to Attribute »

Renaming PhpAttribute to Attribute

php.internals

Benas IML

6 years ago
Hey internals, Since it's safe to say that the Attributes v2 RFC has passed, I wanted to make a separate thread based on the comment by Rowan Tommins in the PHP namespace policy thread. This is a quote from his comment:
> One prefix doesn't make a trend. "PhpToken" is a different case - it's a > token of PHP source code, so the prefix isn't anything to do with > avoiding name collisions, it's a natural clarification. > > To be honest, I'd be perfectly happy with the attributes RFC using the > class name "Attribute", just as we use "Iterator", "Closure", > "Exception", etc, etc. At which point the whole thing's a non-issue.
I do strongly agree with him and I believe we should rename `\PhpAttribute` to simply `\Attribute` before the PHP 8 release in order to improve consistency with other classes and interfaces e. g. Iterator, ArrayAccess, Countable. It would also make the attribute class definition look more aesthetically pleasing: ``` <?php <<Attribute>> class Test {} ``` I am ready to make an RFC for this if the replies are mostly positive, so please, express your opinions! Best regards, Benas Seliuginas P.S: this is my second email account so hopefully it won't get marked as spam.

Marco Pivetta

6 years ago
Heya, On Tue, Apr 28, 2020 at 5:37 PM Benas IML <benas.molis.iml@gmail.com> wrote:
> Hey internals, > > Since it's safe to say that the Attributes v2 RFC has passed, I wanted to > make a separate thread based on the comment by Rowan Tommins in the PHP > namespace policy thread. This is a quote from his comment: > > > One prefix doesn't make a trend. "PhpToken" is a different case - it's a > > token of PHP source code, so the prefix isn't anything to do with > > avoiding name collisions, it's a natural clarification. > > > > To be honest, I'd be perfectly happy with the attributes RFC using the > > class name "Attribute", just as we use "Iterator", "Closure", > > "Exception", etc, etc. At which point the whole thing's a non-issue. > > I do strongly agree with him and I believe we should rename `\PhpAttribute` > to simply `\Attribute` before the PHP 8 release in order to improve > consistency with other classes and interfaces e. g. Iterator, ArrayAccess, > Countable. It would also make the attribute class definition look more > aesthetically pleasing: > > ``` > <?php > <<Attribute>> > class Test {} > ``` > > I am ready to make an RFC for this if the replies are mostly positive, so > please, express your opinions! > > Best regards, > Benas Seliuginas > P.S: this is my second email account so hopefully it won't get marked as > spam. >
`Attribute` is certainly too generic, and will needlessly collide with code in the wild. I suggest circling back to the `PHP\` namespace discussion, and having `PHP\Attribute` if you really have a problem with current naming. Otherwise, we will indeed see more and more `the_php_way_<actual-name-of-symbol>` in future :-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Benas IML

6 years ago
Hello,
> `Attribute` is certainly too generic, and will needlessly collide with code > in the wild.
Could you provide any examples as to where '\Attribute' is being used in the wild? I haven't seen a single project that has an Attribute class and uses the global namespace.
> I suggest circling back to the `PHP\` namespace discussion, and having > `PHP\Attribute` if you really have a problem with current naming.
In regards to `\PHP` namespace, I believe this is future scope and because it's still not voted into PHP, we should do the things like we always did. I believe that the reasoning behind calling the attribute's class as `PhpAttribute` was because the author wanted to be consistent with PhpToken. But since `PhpToken` was called as such to not raise ambiguity to what kind of a token it is, I believe that the attribute class should be simply named `Attribute` instead. Best regards, Benas Seliuginas

Marco Pivetta

6 years ago
Hey Benas, On Tue, Apr 28, 2020 at 5:59 PM Benas IML <benas.molis.iml@gmail.com> wrote:
> > `Attribute` is certainly too generic, and will needlessly collide with > code > > in the wild. > > Could you provide any examples as to where '\Attribute' is being used in > the > wild? I haven't seen a single project that has an Attribute class and uses > the > global namespace. >
Thankfully (to PSRs), I don't write non-namespaced code myself anymore: that's not something that is true in many legacy and closed-source projects. I tend to also healthily avoid any packages that declare symbols in the global namespace. Like many other things in life, just because you don't see something doesn't mean that it is certainly not there ;-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Benas IML

6 years ago
Hey,
> Like many other things in life, just because you don't see something doesn't > mean that it is certainly not there ;-)
I do understand your point and I do agree that there may be some minimal collision but stating that `Attribute` is too generic and will needlessly collide with code in the wild is a fairly bold claim. As such, I asked to back it up. Speaking on the other note, is there any problem on my side but it doesn't seem that I am able to register for a PHP wiki account [1]. I keep getting an error message "That wasn't the answer we were expecting". [1]: https://wiki.php.net/?do=register Best regards, Benas Seliuginas

Benas IML

6 years ago
Hello,
> Speaking on the other note, is there any problem on my side but it doesn't > seem that I am able to register for a PHP wiki account [1]. I keep getting an > error message "That wasn't the answer we were expecting".
This is no longer a problem, I successfully registered my wiki account. Best regards, Benas Seliuginas

Côme Chilliet

6 years ago
Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit :
> Could you provide any examples as to where '\Attribute' is being used in the > wild? I haven't seen a single project that has an Attribute class and uses the > global namespace.
We do use an Attribute class in FusionDirectory: https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc I’d expect a lot of projects to have an Attribute class, since there are things named attributes in lots of contexts.
-- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

Nikita Popov

6 years ago
On Wed, Apr 29, 2020 at 2:51 PM Côme Chilliet < come.chilliet@fusiondirectory.org> wrote:
> Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit : > > Could you provide any examples as to where '\Attribute' is being used in > the > > wild? I haven't seen a single project that has an Attribute class and > uses the > > global namespace. > > We do use an Attribute class in FusionDirectory: > https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc > > I’d expect a lot of projects to have an Attribute class, since there are > things named attributes in lots of contexts. >
Great! You have discovered a nice opportunity to finally move your code into the FusionDirectory namespace. PHP reserves (de facto if not de jure) the global namespace for it's own purposes. If you want to place classes in the global namespace, without prefixing them, that's fine, but please don't complain if there are clashes. Nikita

Côme Chilliet

6 years ago
Le mercredi 29 avril 2020, 14:58:02 CEST Nikita Popov a écrit :
> On Wed, Apr 29, 2020 at 2:51 PM Côme Chilliet < > come.chilliet@fusiondirectory.org> wrote: > > Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit : > > > Could you provide any examples as to where '\Attribute' is being used in > > the > > > wild? I haven't seen a single project that has an Attribute class and > > uses the > > > global namespace. > > > > We do use an Attribute class in FusionDirectory: > > https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc > > > > I’d expect a lot of projects to have an Attribute class, since there are > > things named attributes in lots of contexts. > > Great! You have discovered a nice opportunity to finally move your code > into the FusionDirectory namespace. > > PHP reserves (de facto if not de jure) the global namespace for it's own > purposes. If you want to place classes in the global namespace, without > prefixing them, that's fine, but please don't complain if there are clashes.
This is a bit harsh, I did not complain, I provided an example of project to someone who wrote «Could you provide any examples». I can, so I did.
-- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

Nikita Popov

6 years ago
On Wed, Apr 29, 2020 at 3:24 PM Côme Chilliet < come.chilliet@fusiondirectory.org> wrote:
> Le mercredi 29 avril 2020, 14:58:02 CEST Nikita Popov a écrit : > > On Wed, Apr 29, 2020 at 2:51 PM Côme Chilliet < > > come.chilliet@fusiondirectory.org> wrote: > > > Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit : > > > > Could you provide any examples as to where '\Attribute' is being > used in > > > the > > > > wild? I haven't seen a single project that has an Attribute class and > > > uses the > > > > global namespace. > > > > > > We do use an Attribute class in FusionDirectory: > > > > https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc > > > > > > I’d expect a lot of projects to have an Attribute class, since there > are > > > things named attributes in lots of contexts. > > > > Great! You have discovered a nice opportunity to finally move your code > > into the FusionDirectory namespace. > > > > PHP reserves (de facto if not de jure) the global namespace for it's own > > purposes. If you want to place classes in the global namespace, without > > prefixing them, that's fine, but please don't complain if there are > clashes. > > This is a bit harsh, I did not complain, I provided an example of project > to someone who wrote «Could you provide any examples». > I can, so I did. >
Sorry for the snark! To rephrase my mail in a more neutral fashion: I don't think we should be taking potential naming clashes *in the global namespace* into account at all, independently of whether we know that specific clashes exist or not. The only naming clashes we should be concerned about are those that affect namespaced code. However, these are only created by the introduction of new keywords, or new reserved class names (like "mixed" if we introduce a mixed type), not the introduction of new classes. Nikita

Derick Rethans

6 years ago
On Wed, 29 Apr 2020, Nikita Popov wrote:
> On Wed, Apr 29, 2020 at 3:24 PM Côme Chilliet < > come.chilliet@fusiondirectory.org> wrote: > > > Le mercredi 29 avril 2020, 14:58:02 CEST Nikita Popov a écrit : > > > On Wed, Apr 29, 2020 at 2:51 PM Côme Chilliet < > > > come.chilliet@fusiondirectory.org> wrote: > > > > Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit : > > > > > > > > > Could you provide any examples as to where '\Attribute' is > > > > > being used in the wild? I haven't seen a single project that > > > > > has an Attribute class and uses the global namespace. > > > > > > > > We do use an Attribute class in FusionDirectory: > > > > https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc > > > > > > > > I’d expect a lot of projects to have an Attribute class, since > > > > there are things named attributes in lots of contexts. > > > > > > Great! You have discovered a nice opportunity to finally move your > > > code into the FusionDirectory namespace. > > > > > > PHP reserves (de facto if not de jure) the global namespace for > > > it's own purposes. If you want to place classes in the global > > > namespace, without prefixing them, that's fine, but please don't > > > complain if there are clashes. > > > > This is a bit harsh, I did not complain, I provided an example of > > project to someone who wrote «Could you provide any examples». I > > can, so I did. > > Sorry for the snark! > > To rephrase my mail in a more neutral fashion: I don't think we should > be taking potential naming clashes *in the global namespace* into > account at all, independently of whether we know that specific clashes > exist or not.
This is also documented already in the manual: https://www.php.net/manual/en/userlandnaming.rules.php "PHP owns the top-level namespace but tries to find decent descriptive names and avoid any obvious clashes." cheers, Derick
-- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug

Benas IML

6 years ago
Hello, Since your project is just a single example, we still can't make such a bold claim that `\Attribute` is used a lot. While "attribute" is a fairly generic word, just about everyone uses namespaced classes and therefore it's not a huge problem. Moreover, PHP 8 is a major release so BC in such cases isn't the first priority. Also, it's important to mention that the introduction of functions such as `str_contains()` is also a breaking change for some. But the benefits it provides outweigh the 0.1% who may get BC issues. Best regards, Benas Seliuginas

Chase Peeler

6 years ago
On Wed, Apr 29, 2020 at 9:35 AM Benas IML <benas.molis.iml@gmail.com> wrote:
> Hello, > >
I honestly don't care what it's called, but I am seeing some arguments being used in favor of changing it that I think are invalid.
> Since your project is just a single example, we still can't make such a > bold > claim that `\Attribute` is used a lot. > >
As with any possible BC break, the issue isn't what we know, but what we don't know. It's the potential impact to closed source or other proprietary projects out there, weighed against the benefit. Since "Attribute" is a pretty common term in programming, the odds of some of those projects having an Attribute class in the global namespace is higher than some esoteric term rarely used in a programming context.
> While "attribute" is a fairly generic word, just about everyone uses > namespaced > classes and therefore it's not a huge problem. Moreover, PHP 8 is a major > release so BC in such cases isn't the first priority. > >
Again, your assumption that just about everyone uses namespaced classes doesn't take into account closed source projects. I don't care if it's a major release or not - BC breaks should always be avoided without a major benefit
> Also, it's important to mention that the introduction of functions such as > `str_contains()` is also a breaking change for some. But the benefits it > provides outweigh the 0.1% who may get BC issues. > >
str_contains adds functionality to PHP. We aren't debating whether to add attribute functionality to PHP, but what to call it. As such, this argument is an invalid comparison.
> Best regards, > Benas Seliuginas >
I don't think PhpAttribute is a bad name. Per the RFC: "Attributes as a form of structured, syntactic metadata to declarations of classes, properties, functions, methods, parameters and constants. Attributes allow to define configuration directives directly embedded with the declaration of that code." - In other words, they are Attributes of PHP constructs. While that additional Php might not be necessary to avoid ambiguation in the same way it was for Token, I don't think it's an improper disambiguation either. As Derick said below "PHP owns the top-level namespace but tries to find decent descriptive names and avoid any obvious clashes." - These seems like a prime example of using "descriptive names" to "avoid any obvious clashes" As I said above, I'm ambivalent about this particular issue. However, I get nervous when I start to see the "Who cares if it breaks stuff" or "Well, they shouldn't be doing it that way, so screw them" arguments pop up. While the chances of a BC break might be minimal using "Attribute" - I don't think that PhpAttribute is an undue burden in an attempt to avoid such instances, nor is it logically inconsistent with other Php* named classes.
-- Chase Peeler chasepeeler@gmail.com

Rowan Collins

6 years ago
On 29/04/2020 15:41, Chase Peeler wrote:
> I don't think PhpAttribute is a bad name [...] nor is it logically inconsistent with other Php* named classes.
One of the things I dislike about "PhpAttribute" is that it's still really generic - I know I'm writing PHP, so it feels like broken Hungarian notation ("class FooClass extends BarInterface") rather than an actual name. As for "other Php* named classes", as far as I know, we have exactly one, PhpToken, and that's not even in any released version yet. Possibly that name is also poor, and it should be renamed "ParserToken" or "PhpSourceToken", but at least it can be read as "a token of PHP". As I was writing my last message, I looked for examples of other very generic classes that we've added to core, and came upon "Error". Like "Attribute", that's an extremely common term, with meanings in various contexts. If "PhpAttribute" means "an attribute applied to PHP code", then "an error thrown by the PHP engine" ought to be "PhpError", but I don't remember that name even being suggested. So, if we do think "Attribute" is too generic a name, perhaps someone can suggest a better one, rather than just sticking the letters "PHP" in front. Regards,
-- Rowan Tommins (né Collins) [IMSoP]

Benas IML

6 years ago
Hello,
> Again, your assumption that just about everyone uses namespaced classes > doesn't take into account closed source projects. I don't care if it's a
major
> release or not - BC breaks should always be avoided without a major
benefit With an introduction of any new language construct, function, class or constant, we don't know whether it affects closed source projects and we can't. So using your own logic, you can't assume that closed source projects use `Attribute` either. Another key term to take into consideration from my email is "in such cases isn't the first priority". That doesn't mean it doesn't matter, so please don't change my words as you please. Since PHP has global namespace reserved, things like implementation details matter much more **in such cases**.
> str_contains adds functionality to PHP. We aren't debating whether to add > attribute functionality to PHP, but what to call it. As such, this
argument is
> an invalid comparison.
What I meant by `str_contains()` was its name. There were multiple PHP projects that offered a global helper function called `str_contains()`. As such, introduction of this function was also a name clash for them.
> As I said above, I'm ambivalent about this particular issue. However, I
get
> nervous when I start to see the "Who cares if it breaks stuff" or "Well,
they
> shouldn't be doing it that way, so screw them" arguments pop up. While the > chances of a BC break might be minimal using "Attribute" - I don't think
that
> PhpAttribute is an undue burden in an attempt to avoid such instances,
nor is
> it logically inconsistent with other Php* named classes.
Well then you shouldn't take everything so "harshly" and as a debate. There are no "arguments" here, I am simply expressing my own opinion. As for naming inconsistencies, Rowan addressed that already. Best regards, Benas Seliuginas.

Davey

6 years ago
On Wed, Apr 29, 2020 at 08:24 Benas IML <benas.molis.iml@gmail.com> wrote:
> Hello, > > > Again, your assumption that just about everyone uses namespaced classes > > doesn't take into account closed source projects. I don't care if it's a > major > > release or not - BC breaks should always be avoided without a major > benefit > > With an introduction of any new language construct, function, class or > constant, we don't know whether it affects closed source projects and we > can't. > So using your own logic, you can't assume that closed source projects use > `Attribute` either. > > Another key term to take into consideration from my email is "in such cases > isn't the first priority". That doesn't mean it doesn't matter, so please > don't > change my words as you please. Since PHP has global namespace reserved, > things > like implementation details matter much more **in such cases**. > > > str_contains adds functionality to PHP. We aren't debating whether to add > > attribute functionality to PHP, but what to call it. As such, this > argument is > > an invalid comparison. > > What I meant by `str_contains()` was its name. There were multiple PHP > projects > that offered a global helper function called `str_contains()`. As such, > introduction of this function was also a name clash for them. > > > As I said above, I'm ambivalent about this particular issue. However, I > get > > nervous when I start to see the "Who cares if it breaks stuff" or "Well, > they > > shouldn't be doing it that way, so screw them" arguments pop up. While > the > > chances of a BC break might be minimal using "Attribute" - I don't think > that > > PhpAttribute is an undue burden in an attempt to avoid such instances, > nor is > > it logically inconsistent with other Php* named classes. > > Well then you shouldn't take everything so "harshly" and as a debate. There > are > no "arguments" here, I am simply expressing my own opinion. > > As for naming inconsistencies, Rowan addressed that already. > > Best regards, > Benas Seliuginas.
Hi all, IMO, the onus of proof should be on those wishing to introduce a change that has a potential conflict, not those trying to prevent one. I believe that using the PHP namespace is the right way to go, and look forward to seeing code like this in the future: <?php namespace Dshafik; use PHP\Attribute; <<Attribute>> class Foo { } - Davey

Rowan Collins

6 years ago
On 2 May 2020 08:23:14 BST, Davey Shafik <davey@php.net> wrote:
>IMO, the onus of proof should be on those wishing to introduce a change >that has a potential conflict, not those trying to prevent one.
While I totally understand the principle here, it does lead to two questions: 1) What evidence would you accept that this change was safe? I published my findings from looking through 200 search results here: https://externals.io/message/109880#109927 Is that enough for you to draw a conclusion one way or another? 2) Why now? Why is this particular class's introduction facing a higher hurdle than anything previously? Is it that previous introductions were "obviously" safe enough (I certainly wouldn't put "Error" in that category)? Or perhaps previous introductions did cause people problems, and we need to change policy to avoid repeating those?
> I believe that using the PHP namespace is the right way to go
I'm inclined to agree, as a general policy, but I wouldn't want to see Php\Attrtibute introduced without two things: - an agreed definition of which classes are expected to be added to the namespace (e.g. core language features vs extension functionality) - a plan to rename those existing classes that clearly meet the definition - probably things like Error, Closure, and Generator Otherwise, it just becomes one more inconsistency for users to remember ("X was added in 8.1, so it needs a use statement, but Y is older, so doesn't"). Regards,
-- Rowan Tommins [IMSoP]

Ben Ramsey

6 years ago
> Davey Shafik wrote: > >> I believe that using the PHP namespace is the right way to go, and look >> forward to seeing code like this in the future: >> >> <?php >> namespace Dshafik; >> >> use PHP\Attribute; >> >> <<Attribute>> >> class Foo { }
> Chase Peeler wrote: > >> I don't think PhpAttribute is a bad name [...] nor is it logically inconsistent with other Php* named classes.
> Rowan Tommins wrote: > >> One of the things I dislike about "PhpAttribute" is that it's still really generic - I know I'm writing PHP, so it feels like broken Hungarian notation ("class FooClass extends BarInterface") rather than an actual name.
I’ve been trying to think through other naming schemes that could set a good precedent for these discussions as we move forward, since I think this will continue to be a topic of discussion. So, I tried to think of alternate schemes, such as introducing a root-level attributes namespace (e.g. `Attributes\Attribute` and `Attributes\CompilerAttribute`, or `PhpAttributes\Attribute`, etc.), but that would see arbitrary namespaces proliferate in the core, and the potential for collisions with userland code would be even greater. I’m starting to come around to Davey’s way of thinking here, but I don’t know if I’m quite there yet. Perhaps we change `PhpCompilerAttribute` to `CompilerAttribute` and rename `Attribute`/`PhpAttribute` to `UserlandAttribute`? It seems that’s the distinction we’re attempting to make with these names. Cheers, Ben

Rowan Collins

6 years ago
On 29/04/2020 13:50, Côme Chilliet wrote:
> Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit : >> Could you provide any examples as to where '\Attribute' is being used in the >> wild? I haven't seen a single project that has an Attribute class and uses the >> global namespace. > We do use an Attribute class in FusionDirectory: https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc
Thanks. I clicked through a few results on GitHub (most of which were incorrect matches) and all 220 results from this search (nearly all of which were in a namespace, so unaffected): https://grep.app/search?q=class%20Attribute&case=true&words=true&filter[lang][0]=PHP That yielded these further examples: * https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikiLexicalData/+/master/OmegaWiki/Attribute.php * https://github.com/opensourcepos/opensourcepos/blob/master/application/models/Attribute.php * https://github.com/yupe/yupe/blob/master/protected/modules/store/models/Attribute.php * https://github.com/leenooks/phpLDAPadmin/blob/master/lib/Attribute.php * https://github.com/swipestripe/silverstripe-swipestripe/blob/master/code/product/Attribute.php * https://github.com/Nerdmind/Blog/blob/master/core/namespace/Attribute.php * https://github.com/MISP/MISP/blob/2.4/app/Model/Attribute.php FWIW, most of these seem to be one-to-one mappings from a database table name to a data object. There's also some hints that PrestaShop has a class name that would be affected; the actual file shipped is called "AttributeCore" (https://github.com/PrestaShop/PrestaShop/blob/develop/classes/Attribute.php), but there's some magic in the autoloader which may explain some of the references I'm seeing (https://github.com/PrestaShop/PrestaShop/blob/develop/classes/PrestaShopAutoload.php).
> I’d expect a lot of projects to have an Attribute class, since there are things named attributes in lots of contexts.
The reason I wouldn't expect it to be that common is precisely because it's such a generic term, so projects might well avoid it as a) too vague; and b) too likely to conflict across the application. It's certainly going to affect some people, but I'm not convinced it's more likely to conflict than any of the dozens of previous classes that have been added to core over the years. I imagine claiming it in the root namespace will have a similar impact to claiming "Error" in PHP 7.0, which I don't remember a big debate about that at the time. Regards,
-- Rowan Tommins (né Collins) [IMSoP]

Rowan Collins

6 years ago
On Tue, 28 Apr 2020 at 16:43, Marco Pivetta <ocramius@gmail.com> wrote:
> `Attribute` is certainly too generic, and will needlessly collide with code > in the wild. >
I wonder how true that is, precisely because it *is* so generic, so people will likely have used it with a prefix or in their own namespace. It might be interesting to get some stats before burdening the language with more inconsistency.
> I suggest circling back to the `PHP\` namespace discussion, and having > `PHP\Attribute` if you really have a problem with current naming.
That would be a second-best, in my opinion; less arbitrary than "PhpAttribute", but still awkwardly inconsistent with the rest of the language unless we have plans to move other things that feel like the same category, such as Throwable, Exception, Closure, etc. Regards,
-- Rowan Tommins [IMSoP]

Aaron Piotrowski

6 years ago
> On Apr 28, 2020, at 10:37 AM, Benas IML <benas.molis.iml@gmail.com> wrote: > > Hey internals, > > Since it's safe to say that the Attributes v2 RFC has passed, I wanted to > make a separate thread based on the comment by Rowan Tommins in the PHP > namespace policy thread. This is a quote from his comment: > >> One prefix doesn't make a trend. "PhpToken" is a different case - it's a >> token of PHP source code, so the prefix isn't anything to do with >> avoiding name collisions, it's a natural clarification. >> >> To be honest, I'd be perfectly happy with the attributes RFC using the >> class name "Attribute", just as we use "Iterator", "Closure", >> "Exception", etc, etc. At which point the whole thing's a non-issue. > > I do strongly agree with him and I believe we should rename `\PhpAttribute` > to simply `\Attribute` before the PHP 8 release in order to improve > consistency with other classes and interfaces e. g. Iterator, ArrayAccess, > Countable. It would also make the attribute class definition look more > aesthetically pleasing: > > ``` > <?php > <<Attribute>> > class Test {} > ``` > > I am ready to make an RFC for this if the replies are mostly positive, so > please, express your opinions! > > Best regards, > Benas Seliuginas > P.S: this is my second email account so hopefully it won't get marked as > spam. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I too strongly agree that attributes should use `Attribute` over `PhpAttribute` or even `PHP\Attribute`. Namespaces for bundled classes probably should be used in the future, but for logically grouped classes (such as DOM), extensions, etc. Attributes are a basic language feature, and therefore should live in the global namespace the same way as Throwable, Iterator, Countable, etc. I did not want naming to be a blocker on the attributes RFC, but it certainly bothered me that it was not `<<Attribute>>`. Please put together an RFC for this name change, I would definitely vote yes. Regards, Aaron Piotrowski

Nikita Popov

6 years ago
On Tue, Apr 28, 2020 at 6:21 PM Aaron Piotrowski <aaron@trowski.com> wrote:
> > > On Apr 28, 2020, at 10:37 AM, Benas IML <benas.molis.iml@gmail.com> > wrote: > > > > Hey internals, > > > > Since it's safe to say that the Attributes v2 RFC has passed, I wanted to > > make a separate thread based on the comment by Rowan Tommins in the PHP > > namespace policy thread. This is a quote from his comment: > > > >> One prefix doesn't make a trend. "PhpToken" is a different case - it's a > >> token of PHP source code, so the prefix isn't anything to do with > >> avoiding name collisions, it's a natural clarification. > >> > >> To be honest, I'd be perfectly happy with the attributes RFC using the > >> class name "Attribute", just as we use "Iterator", "Closure", > >> "Exception", etc, etc. At which point the whole thing's a non-issue. > > > > I do strongly agree with him and I believe we should rename > `\PhpAttribute` > > to simply `\Attribute` before the PHP 8 release in order to improve > > consistency with other classes and interfaces e. g. Iterator, > ArrayAccess, > > Countable. It would also make the attribute class definition look more > > aesthetically pleasing: > > > > ``` > > <?php > > <<Attribute>> > > class Test {} > > ``` > > > > I am ready to make an RFC for this if the replies are mostly positive, so > > please, express your opinions! > > > > Best regards, > > Benas Seliuginas > > P.S: this is my second email account so hopefully it won't get marked as > > spam. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > I too strongly agree that attributes should use `Attribute` over > `PhpAttribute` or even `PHP\Attribute`. > > Namespaces for bundled classes probably should be used in the future, but > for logically grouped classes (such as DOM), extensions, etc. > > Attributes are a basic language feature, and therefore should live in the > global namespace the same way as Throwable, Iterator, Countable, etc. > > I did not want naming to be a blocker on the attributes RFC, but it > certainly bothered me that it was not `<<Attribute>>`. >
+1 Nikita

Niklas Keller

6 years ago
Hey Benas, I've also tried to get that change into the original RFC, but wasn't able to. I'm in favor of an amendment RFC to change the name to Attribute. Best, Niklas Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML <benas.molis.iml@gmail.com>:

Benas IML

6 years ago
Hey internals, Since this is just an implementation detail, Benjamin will submit a new PR himself (after merging Attributes v2 into PHP) to rename `PhpAttribute`. As such, I am not making a separate RFC. Best regards, Benas Seliuginas.

Niklas Keller

6 years ago
Hey Benas, a question has come up whether we even need the PhpAttribute / Attribute attribute at all. We could prevent any conflict if we just delete it. Best, Niklas Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML <benas.molis.iml@gmail.com>:

Nikita Popov

6 years ago
On Sat, May 2, 2020 at 5:57 PM Niklas Keller <me@kelunik.com> wrote:
> Hey Benas, > > a question has come up whether we even need the PhpAttribute / > Attribute attribute at all. We could prevent any conflict if we just > delete it. > > Best, > Niklas >
We need Attribute so static analysis tooling and IDEs can check whether a class is intended to be used as an attribute. I believe there are also plans to extend this functionality to allow specifying more constraints, such as which elements the attribute may target and whether it can appear multiple times. All of these things can be implemented in code, but having them encoded as (attribute) metadata makes the information accessible to introspection and tooling. Nikita

Benas IML

6 years ago
Hello, You should ask Benjamin this question as he is the Attributes RFC author. From my standpoint, I don't really believe we can remove it. As without it, any class would be considered as an attribute - even one that isn't supposed to be. Best regards, Ben.

A.L.E.C

6 years ago
On 02.05.2020 18:02, Benas IML wrote:
> From my standpoint, I don't really believe we can remove it. As without it, > any class would be considered as an attribute - even one that isn't > supposed to be.
I don't remember if it was considered, but... why not define attributes with "class attribute", "attribute class" or just "attribute"? Then PhpAttribute would not be needed.
-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

6 years ago
It will make "attribute" a reserved keyword, which caused more BC break comparing to Attribute class. Regards, CHU Zhaowei -----Original Message----- From: Aleksander Machniak <alec@alec.pl> Sent: Sunday, May 3, 2020 1:38 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Renaming PhpAttribute to Attribute On 02.05.2020 18:02, Benas IML wrote:
> From my standpoint, I don't really believe we can remove it. As > without it, any class would be considered as an attribute - even one > that isn't supposed to be.
I don't remember if it was considered, but... why not define attributes with "class attribute", "attribute class" or just "attribute"? Then PhpAttribute would not be needed.
-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php