Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103971
MIME-Version: 1.0
References: <CAFPFaM+cEa2xFDqvkLQk=Qht3KdcGUCBaCj6JcuQxqLmjnf9Pw@mail.gmail.com>
 <0243D3A4-2C15-4B31-81A8-C2E5892913F9@koalephant.com> <CAFPFaM+9fWQL+oyfwAKAyjohWHO47W=ibzNmpuM9qVA+6JMjig@mail.gmail.com>
 <CAFLRTJ_SmnAT2QaHqinjAQYJBiS2_LfpB47Ph-=K=8FsB+0xXw@mail.gmail.com>
 <2d8efb96-ed1f-28e4-e0fe-603a2d0f1962@gmail.com> <CAAfnsFVaVAAJ4Q3fCvNVABw3d5Ze9BB6+RcQqZmdcPxbRzSi0w@mail.gmail.com>
 <cf338b9b-64cf-efb9-9e9e-7e97c767ff9d@gmail.com> <CAAfnsFUtopcyprU+o23sCssKF+tpTD=n0zA6x0ewg7J3TKEosA@mail.gmail.com>
 <CALKiJKqfp1PmmKTbs1otijhSOQgnhmxe1Cr+Bb9HoC269qX-bg@mail.gmail.com>
 <CAG9XoMTezATGFpkEqSw7+6pqCnVzU6Jc2f7GA7wUeUD0rpdkCQ@mail.gmail.com>
 <CALKiJKrNZSh183b-HDcq9nVL7zZEhwRGx2D5SaJsbX58Wi91bA@mail.gmail.com> <CAG9XoMQ+k6s23Rz2i8qCRn4M2yoyOy1EXOLC=jmffsQGjCL-bw@mail.gmail.com>
In-Reply-To: <CAG9XoMQ+k6s23Rz2i8qCRn4M2yoyOy1EXOLC=jmffsQGjCL-bw@mail.gmail.com>
Date: Fri, 1 Feb 2019 10:11:01 +0000
Message-ID: <CALKiJKqzbfYC8rciFPtBo5=4KOLn_GFK_rSBVpTXTNsrJZ=_Ow@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: Peter Kokot <peterkokot@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d246e50580d25c18"
Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000d246e50580d25c18
Content-Type: text/plain; charset="UTF-8"

On Thu, 31 Jan 2019 at 22:39, Benjamin Morel <benjamin.morel@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]

--000000000000d246e50580d25c18--