On Aug 23 2024, at 12:27 pm, Stephen Reay <[email protected]> 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.