On 2 May 2020 08:23:14 BST, Davey Shafik <da...@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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
