Re: Resurrecting named parameters
| From: | Jakob Givoni | Date: | Fri, 10 Apr 2020 20:00:06 +0000 |
| Subject: | Re: Resurrecting named parameters | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109587@lists.php.net to get a copy of this message | ||
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.