So my ivory tower remark is on point.
I find this hard to answer, because one message ago the objection was
that I'd never been in a position to make a pragmatic decision, and
now it's that I have too much expertise to relate to ordinary users.
Both can't be the problem. I only mentioned what I do because you'd
told me, flatly, that I hadn't done it.
The problem is the disdain and indifference you've shown to people who's skills aren't up to par with yours.
I don't hold that, and nothing I argued requires it. Wanting fewer
people caught out by a change is a fair instinct to have, I don't
think you're wrong to care about it. My point was narrower and not
about anyone's skill: the existence of unmaintained software shouldn't
permanently freeze the language. That's a claim about deprecation
policy, not about the people running those sites.
And it matters that a deprecation breaks nothing on upgrade day. It
emits a notice; removal is a full major version away, years out. A
site nobody maintains also isn't chasing new PHP majors, the two go
together. For an abandoned plugin to suddenly stop working, someone
must actively move it to a major version that removed the feature.
Does WordPress even allow upgrading to a PHP version its plugins don't
support? I don't know. If a managed host does that somehow, without
checking compatibility, the failure isn't in the language.
for what? The code reads prettier to you.
That isn't the motivation. If that were, I'd let a formatter handle it.
The reasons are a simpler grammar, freeing the `list` keyword for a
possible future `list` type, and removing a redundant construct
newcomers otherwise have to learn for no reason. You can think those
aren't worth the churn; that's a legitimate disagreement. "its
prettier" isn't what's actually being proposed.
And this is what I keep coming back to: why this deprecation in
particular? The same RFC deprecates several other things, and at least
one of them is genuinely harder to migrate than `list()`, which makes
the focus on `list()` odd.
Take the deprecation of `_()` in favour of `gettext()` (which is
reasonable, given `_` is being reserved for another purpose). That
looks like a trivial find-and-replace, but it isn't safe. PHP resolves
an unqualified function call by checking the current namespace first
and only then falling back to global. So inside `namespace App;`, a
bare `_(...)` binds to `App\_` if that function exists, and only
otherwise to the global `_`. Blindly rewriting `_` to `gettext` can
therefore change which function actually runs, if there's an
`App\gettext`, the rewritten call now resolves to it instead of the
global one.
A purely syntactic tool like ast-grep cannot catch that, because it's
a whole-program resolution fact, not a textual one. You'd need a
type-aware linter that indexes the entire codebase to do it safely.
`list()` -> `[]` has none of that. The compiler emits identical
opcodes (see the 3v4l link above). So it's the one case where a
one-line ast-grep rewrite is provably correct. If anything, `list()`
is the *safest* migration in the entire RFC, and the harder ones (the
ones that can actually cause issues) aren't the ones drawing the
objection.
I also doubt the abandoned plugins you're picturing are pristine on
every other deprecation in the RFC and happen to trip only on `list(`.
If "some plugins are unmaintained" blocks this, it blocks all of it,
and PHP should never deprecate anything, and we should freeze the
language as it is now.
Being a better coder doesn't make you a better person.
Where exactly did I give you the impression that I think I'm a better
person? We are having a technical discussion; you are turning it
personal.
Cheers,
Seifeddine