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.

Reply via email to