> The problem comes if the share using the old names *doesn't* decline enough (and how would we even know?).
We can't survey private projects, but we can run automated analysis tools on a large number of open-source projects available on GitHub, and compile statistics from them. I'd be happy to work on such a tool, should it be useful some day. > What if people's muscle memory, their coding standards, their need for progressive compatibility, their tools, the tutorials they follow, the code snippets they copy, all make it easier to just keep using the old names? Then our "deprecation" means nothing, and we are stuck with a long list of aliases to maintain, and people learning the language scratching their heads at inconsistent examples. Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for example, strikes through deprecated method names), and static code analysis tools. > To be more positive, I am all for introducing new ways to do existing things in the language where they have real benefits to the user. For instance, a new file-handling API, with better error handling, and object-based streams, would be great; or a replacement for the frankly awful curl functions. Perhaps even a well-designed implementation of "scalar methods" (e.g. being able to write [1, 2, 3]->map($callback)->filter($callback);) would have users enthusiastic enough that they *want* to upgrade their code to use it... I do agree with you on that point: I'd rather offer brand new APIs, rather than just fixing naming inconsistencies. There is so much more than fixing naming inconsistencies. The error handling, in particular, should be given some love, by throwing exceptions everywhere, instead of returning false / triggering warnings. And I would love, too, either your "scalar methods" approach, or array being an object with built-in map/filter/reduce... ... although it takes us close to "completely new language" territory. Maybe not, if this can be done in a mostly BC way. On Thu, 31 Jan 2019 at 12:43, Rowan Collins <rowan.coll...@gmail.com> wrote: > On Thu, 31 Jan 2019 at 10:53, Benjamin Morel <benjamin.mo...@gmail.com> > wrote: > >> Please forgive my stubborness, too. I fail to see how WordPress >> supporting PHP versions that have been EOL for YEARS can be of any help to >> the community? >> > > I agree, it probably doesn't help the community; but it happens, both in > open source projects, and in the many private code bases which are written > in PHP. The more breaking changes we make in the language, the *more* > likely it is that people will stay on old versions, where their code works > without modification, and have a negative opinion of upgrades. > > > >> Now what prevents PHP from adding consistent function names / APIs, and >> deprecating the older ones? We can keep the old ones for 10 more years if >> you wish, but at least new PHP code can start using the "correct" ones, and >> progressively the share of PHP code out there using the old ones should >> progressively get lower over the years, up to the point where we could >> eventually decide that it's not worth keeping them. >> > > The problem comes if the share using the old names *doesn't* decline > enough (and how would we even know?). What if people's muscle memory, their > coding standards, their need for progressive compatibility, their tools, > the tutorials they follow, the code snippets they copy, all make it easier > to just keep using the old names? Then our "deprecation" means nothing, and > we are stuck with a long list of aliases to maintain, and people learning > the language scratching their heads at inconsistent examples. > > To be more positive, I am all for introducing new ways to do existing > things in the language where they have real benefits to the user. For > instance, a new file-handling API, with better error handling, and > object-based streams, would be great; or a replacement for the frankly > awful curl functions. Perhaps even a well-designed implementation of > "scalar methods" (e.g. being able to write [1, 2, > 3]->map($callback)->filter($callback);) would have users enthusiastic > enough that they *want* to upgrade their code to use it, although it takes > us close to "completely new language" territory. > > If we can persuade every user of PHP that the change is bringing them a > real benefit to outweigh the cost of re-writing and re-learning, then we > can make grand changes to the language; I don't think moving underscores > around will ever do that. > > Regards, > -- > Rowan Collins > [IMSoP] >
