On Aug 23 2024, at 12:27 pm, Stephen Reay <php-li...@koalephant.com> wrote:
>
> The current inconsistencies between symbol types can be avoided in userland 
> in a 100% consistent way. Import or qualify the symbols you use, all the 
> time, and you have 0 inconsistencies or bizarreness in terms of what it used 
> when.

So are you essentially arguing that we should put the burden on the majority of 
users, most of whom (documented by us or not) likely will have no idea what the 
problem is or potential consequences are? BC breaks happen. While I am all for 
avoiding BC breaks when possible, sometimes they make sense -- and I think this 
is a clear example of when it does.
I think you are exaggerating the impact of the BC break here. In fact Ilija 
measured the impact on the top 1000 composer packages:
https://gist.github.com/iluuu1994/4b83481baac563f8f0d3204c697c5551
> I was specifically pointing out that a small number of people complaining 
> about this is a ridiculous reason to even consider the change.
That's one take. Another take is this is an easy win for a few percentage 
points bump in speed, with improved supply-chain security for composer packages 
that has a minimal impact on users.
> Great, how about the solution that doesn't have any BC, and works in every 
> version back to 5.3?
By this logic, we should never introduce BC breaks.
> Great, so then we can resolve this whole thing by adding a footnote to the 
> "Name resolution rules" page in the manual that (a) recommends using 
> qualified names (i.e. prefix with a `\`) and (b) provides deeper details of 
> the reasons for those who care.
>From the perspective of program language _design_ (which is what we're talking 
>about here), the goal is to create a language that helps the developer do 
>something faster/better/easier, not do the wrong thing (slower code, etc.) by 
>default and dump the responsibly for that on developers by expecting them to 
>read a footnote buried in a doc. Especially when the justification is because 
>there's concerns that code written in 2009 won't work anymore.

Reply via email to