> 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
