Hi Chris Riley, I agree with Rowan Tommin's arguments in https://externals.io/message/111161#111179 - I wanted named parameters by default.
Miscellaneous comments: 1. https://wiki.php.net/rfc/renamed_parameters should be moved to "In Discussion" on https://wiki.php.net/rfc/ 2. I think that the RFC title should really mention "Making named parameters opt-in", since that part of the RFC has the largest impact. (e.g. "Renamed parameters and making named parameters opt-in"). (The RFC URL should not be changed) 3. For your examples, I assume you mean "Class Bar extends Foo {" instead of "class Bar {" 4. "Error: cannot call parameter $externalName by name." seems incorrect, I assume "cannot call callBar() with parameter $externalName by name" or something along those lines was intended 5. https://wiki.php.net/rfc/renamed_parameters#attributes still mentions "option 1" and "option 2", but those were removed from the current version of the proposal, making this confusing 6. How will this RFC expect internal functions such as substr_compare() or internal methods such as `ArrayObject::__construct()` included in php-src? What about PECLs - will existing function declaration macros be treated as opted out of or into named parameters? 7. This is missing some details on how reflection and backtrace generation will be affected. I assume `ReflectionParameter->getInternalName(): string`, `ReflectionParameter->getExternalName(): ?string`, etc. will need to be added. getTrace() and getTraceAsString() 8. Renaming parameters offers only a small performance benefit and I don't think it would get used very frequently. It's possible to add `$newName = $oldName; unset($oldName);` (or in most cases, to update the method implementation body). 9. Are declarations such as `function test($:publicName, $nonPublicName) {}` an error? I'd personally prefer https://wiki.php.net/rfc/named_params#positional-only_and_named-only_parameters to allow API designers to explicitly opt out of named parameters. 10. As Rowin Tommins had said, "maintainers of larger OSS projects" is a broad claim and could be clarified (e.g. what fraction of maintainers? Were there polls/discussion threads of maintainers/owners of OSS projects?) Since there are strong objections from some maintainers of supporting always-enabled named parameters, I'd think a useful alternative would be to add a positional-only parameter syntax instead in 8.0, similar to what Python, so that maintainers that want to avoid supporting named parameters in their API can clearly express that in a release requiring ^8.0. This is using syntax for https://www.python.org/dev/peps/pep-0570/#history-of-positional-only-parameter-semantics-in-python for clarity, but obviously other syntax might suit PHP better. (mentioned in https://wiki.php.net/rfc/named_params#positional-only_and_named-only_parameters) ``` function test(int $x, /, string $y) {} test(x: 1, y: "test"); // Error: test() does not support being called with parameter $x by name test(1, y: "test"); // allowed function test_varargs(...$args, /) {} test_varargs(x: 1); // Error: test_varargs() does not support being called with named variable argument $x in ...$args test_varargs(...['x' => 1]); // Error: test_varargs() does not support being called with named variable argument $x in ...$args ``` There may be concerns such as whether `/` can be added when overriding, or in forbidding using `...$newArgs, /` to override `...$originalArgs` but since parameter renaming was already allowed in the Named Arguments RFC this should not be a new issue. Regards, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
