Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109587
MIME-Version: 1.0
References: <CAF+90c8MONp8Qh0E1qtegFb0QyZkqFv2OOirDzJds1LyOV4o5w@mail.gmail.com>
In-Reply-To: <CAF+90c8MONp8Qh0E1qtegFb0QyZkqFv2OOirDzJds1LyOV4o5w@mail.gmail.com>
Date: Fri, 10 Apr 2020 22:00:06 +0200
Message-ID: <CAJmjfvVp4Mf3XWjd5XV9HHaHJnbH=nN6pdoXdZTUezm+DceRmw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Resurrecting named parameters
From: jakob@givoni.dk (Jakob Givoni)

On Tue, Apr 7, 2020 at 2:45 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> ## LSP checks for parameter names
>
> Parameter names currently have no particular significance in PHP, only
> their position in the signature is important. If named parameters are
> introduced (in a way that does not require opt-in at the declaration-site),
> then parameter names become significant. This means that changing a
> parameter name during inheritance constitutes an LSP violation (for
> non-constructor methods). There are a number of ways in which this issue
> may be approached:
>
> 1. Silently ignore the problem. No diagnostic is issued when a parameter
> name is changed during inheritance. An error exception will be thrown when
> trying to use the (now) unknown parameter name.

I prefer this approach. It might seem inelegant at first but I believe
none of the other options will do us any real favors, especially
stronger LSP enforcement on the language level. And opt-in seems like
a non-starter for reasons Rowan Tommins lay out (though he's in favor
:-)
Dev side tools will be fully able to "deal" with the downfall.