On Wed, 23 Jan 2019 at 16:37, Benjamin Morel <benjamin.mo...@gmail.com> wrote:
> > 2.78 million vs. 5.1 million* code references. > > 1.54 million results. > > 10 million results. Broad, active usage. > > ... > > I would not in any way base deprecation decisions on current usage > statistics. If there are several ways to do something, and one is clearly > better than the others (naming consistency) then the choice should IMHO be > imposed to the community. > Every time you impose a change on the community, you are costing that community goodwill, time, and ultimately money. It is absolutely critical that decisions weigh that cost against the expected benefit. If the expected benefit is a small increase in readability, and the expected cost is a huge volume of existing code requiring changes, we should rule out the change. > Trying to make 10+ years old codebases work with recent versions of PHP > without modification slows down development a lot. > Major versions are here to break things. No, major versions are here *to improve the language while breaking as little as possible*. We are not in the business of change for change's sake; every change needs to be justified, regardless of where in the release cycle it comes. > Changelogs and runtime deprecation notices are here to help. > As others have pointed out, runtime deprecation notices have a cost on their own - they create noise in logs, obscuring more important changes, and taking up disk space. Again, this is a cost that needs to be weighed against the expected benefit. Regards, -- Rowan Collins [IMSoP]
