On Thu, 31 Jan 2019 at 22:39, Benjamin Morel <benjamin.mo...@gmail.com> wrote: >> 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. Deprecation notices won't change people's *desire* to change their code. If you raised a deprecation notice for every call to, say "htmlspecialchars", the only result would be people turning off deprecation notices, and missing more important deprecations. >> ... although it takes us close to "completely new language" territory. > Maybe not, if this can be done in a mostly BC way. It wasn't the BC I was worrying about there, but the possibility that projects would adopt one style or the other, and readers coming from an "old-style" project might find the code in a "new-style" project rather alien. In a worst case scenario, it would feel like we had two languages interoperating on the same runtime, like when HHVM hosted both PHP and Hack. It's not inevitable, though, just a risk to think about if we ever get to that position. Regards, -- Rowan Collins [IMSoP]