Re: Renaming PhpAttribute to Attribute

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