Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103972
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> <CALKiJKqzbfYC8rciFPtBo5=4KOLn_GFK_rSBVpTXTNsrJZ=_Ow@mail.gmail.com>
In-Reply-To: <CALKiJKqzbfYC8rciFPtBo5=4KOLn_GFK_rSBVpTXTNsrJZ=_Ow@mail.gmail.com>
Date: Fri, 1 Feb 2019 11:33:53 +0100
Message-ID: <CAG9XoMRkaR0XmPjN97T9SSH3=7FJ9y+-n3=VBUywd9QQCYCB-A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b23efd0580d2ae62"
Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000b23efd0580d2ae62
Content-Type: text/plain; charset="UTF-8"

>  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.

You have a point here. Couldn't we add a "deprecated log" feature, that
would log each deprecated function only once? At least we could leave an
app running for some time, and get a curated list of deprecated features
from the deprecated log.



On Fri, 1 Feb 2019 at 11:11, Rowan Collins <rowan.collins@gmail.com> wrote:

> 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]
>

--000000000000b23efd0580d2ae62--