Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103959
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>
In-Reply-To: <CALKiJKrNZSh183b-HDcq9nVL7zZEhwRGx2D5SaJsbX58Wi91bA@mail.gmail.com>
Date: Thu, 31 Jan 2019 23:39:40 +0100
Message-ID: <CAG9XoMQ+k6s23Rz2i8qCRn4M2yoyOy1EXOLC=jmffsQGjCL-bw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Peter Kokot <peterkokot@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006949c90580c8b4b0"
Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8
From: benjamin.morel@gmail.com (Benjamin Morel)

--0000000000006949c90580c8b4b0
Content-Type: text/plain; charset="UTF-8"

> 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.collins@gmail.com> wrote:

> On Thu, 31 Jan 2019 at 10:53, Benjamin Morel <benjamin.morel@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]
>

--0000000000006949c90580c8b4b0--