Hi John,
On 05/05/2020 18:27, John Bafford wrote:
I very much do like the idea of named parameters, but I do not like the
specific proposal in the linked RFC at all. I think that treating named
parameters simply as syntactic sugar is not a good approach. If we're going to
add named parameters, I think they should actually be significant in their own
right. As such, please allow me to present an alternative.
I would propose the following opt-in mechanism, which would work by treating
the parameter names as*part of the function name*. Doing it this way I_think_
should allow for no backwards compatibility issues with existing code and would
especially give library authors full control over the naming and presentation
of their APIs.
I really like *some* of this proposal, but I think some of it is solving
a different problem.
You mention in a later e-mail that you've been heavily inspired by
Swift; Swift in turn was inspired by Objective C, which was inspired by
Smalltalk. This is an important piece of history, because Smalltalk
doesn't actually have methods with named parameters; it has "keyword
messages" whose "selectors" are things like "indexOf:startingAt:". Swift
makes them look more familiar by keeping part of the name separate from
what it calls "argument labels", so a method might be called
"indexOf(_:startingAt:)" or "index(of:startingAt:)".
Although at a glance these look like named parameters, and they solve
some of the same problems, they're actually a fundamentally different
concept.
They have some nice features:
* Method calls can be made to read like sentences
* The external API of the function is kept separate from the internal
implementation
* You can skip over default arguments by omitting their labels
* Overloading what looks like one method, by having different methods
whose names start the same but have different "argument labels", may be
appealing
But there are some crucial limitations:
* You can't call a method without using its labels; you'd need to have a
separate method with a similar name and no labels
* Similarly, it's up to the method's author to have versions with a
mixture of unlabelled and labelled parameters, so a call like
"create('hello', 42, locked: true)" is only possible if that specific
variant is defined
* You can't use the labels in the "wrong" order, you have to know the
order they come in; so it doesn't solve the haystack/needle problem,
except by creating extra function definitions
* Similarly, methods with large numbers of arguments are still hard to
use because you need to know both the name *and* the relative position
of the arguments you're providing (imagine defining variants with every
order of the 5 bit flags in the AMQP example in my earlier e-mail)
It would be possible to take the "outside name is different from inside
name" concept and apply it to named parameters proper. But the problems
I would like to solve with named parameters wouldn't be solved by
Swift/Smalltalk style functions.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
