Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

This is only part of a thread. view whole thread
  111195
July 26, 2020 18:32 rowan.collins@gmail.com (Rowan Tommins)
Hi Chris,


On 26/07/2020 14:52, Chris Riley wrote:
> Thanks for the feedback so far. In light of the feedback received both here > and privately, I've made 3 changes to the RFC document
Firstly, a reminder of the guideline in the RFC howto that the link to the RFC should be included in replies, which is particularly relevant when announcing changes to the text. For others trying to find it, it is here: https://wiki.php.net/rfc/renamed_parameters Secondly, regardless of the merits of your proposal in itself, I think an RFC in this position should explicitly state why it is proposing to re-visit an accepted feature. I can think of a handful of possible reasons, but none seem to apply: - If new concerns have come to light which are likely to change the opinion of those who voted Yes. This is not the case for the concerns in your introduction. - If the RFC passed only by a narrow margin, or a low turnout, and this version is expected to gain a larger majority. The RFC passed with a ratio of 3:1, with 75 votes cast [1]. - If the RFC discussion was rushed, so that people did not have adequate time to understand the proposal and discuss its implications. The RFC was informally resurrected at the start of April [2] and formally at the start of May [3] and saw plenty of discussion. - If there is evidence that people voted Yes despite reservations that this proposal resolves. No evidence is presented of this, and the only message of that sort in the voting thread expressed reservations unrelated to this proposal. [4] - If there is evidence that (a significant number of) people who voted Yes have now changed their minds having re-considered the implications. No evidence is presented of this. As Benjamin says, the pragmatic way forward would be to discuss enhancements on top of the accepted feature, rather than last-minute alternatives to it. [1] This appears to be the second highest turnout after Scalar Type Declarations, according to https://php-rfc-watch.beberlei.de/ [2] https://externals.io/message/109549 [3] https://externals.io/message/110004 [4] https://externals.io/message/110910#110961 Regards, -- Rowan Tommins (né Collins) [IMSoP]
  111207
July 28, 2020 04:33 tysonandre775@hotmail.com (tyson andre)
Hi internals,

Continuing on my response in https://externals.io/message/111161#111192 , and considering ways to enhance named arguments without a BC break
(while minimizing the impact on application/library authors that wish for their libraries not to be used with named parameters)

I was considering setting up a short straw poll on the wiki for a week with two questions, open for a week:

1. Whether voters consider it appropriate to add amendments/enhancements to named parameters (in general) in php 8.0 past the feature freeze. (Both/Backward Compatible Enhancements Only/No)
   (yes if interested in any of the alternatives proposed in https://externals.io/message/111161)

   I'd recognize that named parameters are potentially a large change to what is considered the public API of a project,
   so I'd think continuing to add enhancements would be worthwhile, but I'd like to know where others stand on this.
   (e.g. if any proposals I made should be postponed to 8.1)

   I'd also think that implementing a backwards incompatible change after the feature freeze (in terms of impact on code targeting 8.0 alphas at the time of the feature freeze)
    would be a bad precedent.

2. Interest in adding support for positional-only arguments in 8.0 or 8.1 (3 options: 8.0, 8.1, or no)

   (e.g. with a symbol such as `/` to indicate that parameters or variadic parameters prior to the symbol are positional-only)

   I'd consider positional-only arguments useful in some cases, such as where the names would always be confusing,
   (or automatically generated code)

   - `function my_merge(string $firstArg, ...string $otherArgs, /) { }`
     This also provides an easy way for user-defined code to add restrictions similar to what `array_merge()` already has.
   - `function my_pow($x, $y, $z = null, /,) {}`
   - `function autoGeneratedCode($arg1, $arg2, /) {}

   Other syntaxes are possible, such as using attributes
   (I would find 5 attributes rather verbose if there were 5 positional-only parameters),
   or keywords such as `__END_POSITIONAL_PARAMETERS`.
   Nothing stood out as a good option (e.g. `_`, `...`, `%` seem meaningless, `*` would be the opposite of python, `#` can't be used),
   and I've only seen markers for the end of positional-only parameters in python after a quick check, so at least some users would find `/` easier to learn/remember.

--------

On an unrelated note,

1. A few people had suggested adding a line to a README indicating that named parameters aren't supported.
An idea I had was to standardize on a machine-readable file format (e.g. ".php_analysis_config.json") that IDEs/analyzers may choose to support.
It might have JSON entries such as `"supports_named_parameters": false` to indicate that code (e.g. src/main.php) using files in that directory (e.g. vendor/a/b/ with vendor/a/b/.php_analysis_config.json)
should not invoke functions/methods in vendor/a/b/ with named parameters,
because there is no guarantee the names will remain the same.
(TOML or ini settings might be more readable, but a complicated format requires extra dependencies and ini files won't support arrays if future settings get added)

- I can't think of many other settings I'd want there that aren't covered by composer.json, editorconfig, or other means.
  Maybe less importantly `"supports_classes_being_extended": bool`
- Alternately, it might be possible to put it in "extra" of composer.json,
  but some projects/libraries don't use composer.json (e.g. a project has both vendor/ and third-party/)
- I'm not aware of similar indicators for python for named arguments, so there might not be much interest in such a proposal. Then again, I think python had named arguments for much longer.

2. Another attribute idea I had was `<>` on a class/method,
to make PHP enforce that method overrides other than __construct must
have the same names in the same positions and not lead to errors when valid named arguments are passed to subclasses,
but I don't plan to propose that any earlier than 8.1
(e.g. for classes that have calls such as `$this->method(someFlag: true);`)

Thanks,
- Tyson