On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita....@gmail.com> wrote:
> Hi internals, > > I've recently started a thread on resurrecting the named arguments > proposal (https://externals.io/message/109549), as this has come up > tangentially in some recent discussions around attributes and around object > ergonomics. > > I've now updated the old proposal on this topic, and moved it back under > discussion: https://wiki.php.net/rfc/named_params > > Relative to the last time I've proposed this around PHP 5.6 times, I think > we're technically in a much better spot now when it comes to the support > for internal functions, thanks to the stubs work. > > I think the recent acceptance of the attributes proposal also makes this a > good time to bring it up again, as phpdoc annotations have historically had > support for named arguments, and this will make migration to the > language-provided attributes smoother. > Regarding the question of what to do with regard to LSP validation and parameter names changing during inheritance: During internal discussion, the following option has come up as a possible compromise: 1. When calling a method, also allow using parameter names from the parent class/interface. 2. During inheritance, enforce that the same parameter name is not used at different positions. This ensures that renaming parameter names during inheritance does not break code relying on parameter names of the parent method. At the same time, it prohibits genuine LSP violations, where a parameter has been moved to a different position. I've run some static analysis to detect cases that would be affected by the latter check, with these results: https://gist.github.com/nikic/6cc9891381a83b8dca5ebdaef1068f4d The first signature is the child method, and the second the parent method. I did not put in the effort to make this completely precise, so there's both false positives and false negatives here. But it should be enough for a general impression. And the general impression is that these are indeed legitimate LSP violations. This approach would be an alternative to either silently ignoring the issue (as the RFC proposed), or to warning for all parameter renames. Regards, Nikita
