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.
Heya,
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\Attributebefore 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
Hello,
Attributeis 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\Attributeif 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
Hey Benas,
Attributeis 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
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".
Best regards,
Benas Seliuginas
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
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
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.incI’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
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.incI’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
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:
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
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.incI’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
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
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\Attributeis 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
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]
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.
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
benefitWith 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
Attributeeither.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 calledstr_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
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:
-
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?
-
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]
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
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://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/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]
Attributeis 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\Attributeif 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]
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\Attributebefore 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.--
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
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\Attributebefore 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.--
I too strongly agree that attributes should use
Attributeover
PhpAttributeor evenPHP\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
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:
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\Attributebefore 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.
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.
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:
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\Attributebefore 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.
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
Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML
benas.molis.iml@gmail.com: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\Attributebefore 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.
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.
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
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
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