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.
