Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108185
MIME-Version: 1.0
References: <CAF+90c-YHBKfMG1foO6HZWeyD5h2WnQFN5fmXG9V2sZ_uFRW-A@mail.gmail.com>
 <AM6PR09MB33179863985F88717A71D562E2390@AM6PR09MB3317.eurprd09.prod.outlook.com>
 <CAF+90c9CJFtTp-TbkLVrBRfa96m_+YzHVNs1byibS+YBK4MJxQ@mail.gmail.com>
 <CANUQDChLphpeh2Sn03Xk+E7bWeP6mdqSBXD-tkBkqmnTw4ybGA@mail.gmail.com> <CAF+90c-8O1RJ2Em2Qac3Bnda7BeeVmZi66moVMi5CRf56Yom7Q@mail.gmail.com>
In-Reply-To: <CAF+90c-8O1RJ2Em2Qac3Bnda7BeeVmZi66moVMi5CRf56Yom7Q@mail.gmail.com>
Date: Fri, 17 Jan 2020 18:10:13 +0000
Message-ID: <CAKtGGAu6=TfQcXf47ThTgAxW+v9b2YUTEwNNr-AFSdBqE=OpRQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Niklas Keller <me@kelunik.com>, Bob Weinand <bobwei9@hotmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000014cf56059c59db12"
Subject: Re: [PHP-DEV] Warn when declaring required parameter after optional one
From: cdtreeks@gmail.com (Aran Reeks)

--00000000000014cf56059c59db12
Content-Type: text/plain; charset="UTF-8"

Hi all,

Whilst I totally see the benefits of this, I'm not sure if this is a job
for PHP itself, rather a coding standard enforced optionally by something
like PHPCS. It's certainly a bad practice, but I'm not sure the benefit
will be worth the refactors required.

I feel we might be an interesting example, however, it'd cause us a lot of
pain for the following reason:

We have a portion of our codebase (shared over hundreds of websites) which
is symlinked into each of the websites so the core functionality can be
easily updated when required on all sites. These sites are staggered at
present across multiple PHP versions whilst being migrated (and due to the
number of sites to migrate, they will be for some time).

If this change were to come into effect, the same code we've safely had
symlinked running across multiple PHP versions would suddenly become
incompatible on the latest version, with no easy way to be suppressed which
would mean we have to fork things and maintain two codebases.

I appreciate this isn't likely to be a normal workflow for people, but it
is an example of how it could cause unintended pain.

Just my thoughts anyway.

Cheers,
Aran

On Fri, 17 Jan 2020 at 18:00, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sat, Jan 11, 2020 at 2:35 PM Niklas Keller <me@kelunik.com> wrote:
>
> > Hi Nikita,
> >
> > while this is a rather small change, it has quite some BC impact, as
> > not all old code has been adjusted to run on PHP 7.1+ only using
> > nullable types.
> >
> > I'd like to see an RFC with a vote for this.
> >
> > Regards,
> > Niklas
> >
>
> I was interested in seeing how prevalent this pattern, is, so I ran some
> analysis on the top 2k composer packages. I found 527 signatures that would
> throw a deprecation warning with this change. Of these 187 are potentially
> used as "poor man's nullable types" (the optional argument has both a type
> and a null default), while the other 340 are definite bugs.
>
> Regards,
> Nikita
>

--00000000000014cf56059c59db12--