Hi John,
On 6 May 2020 19:18:41 BST, John Bafford <jbaff...@zort.net> wrote:
You're not wrong here, but, I think that's an (critical) implementation
detail of Objective-C and Smalltalk that is not relevant here. Also,
Swift does not use selectors or message passing, unless either
interoperating with ObjC classes, or the code has explicitly opted-in.
Normally, Swift function/method calls are statically determined at
compile time in a way similar to C/C++.
It may not use the same mechanism to dispatch them, but the concept of
"parameter labels are part of the function name" is still very much
present, and is very different from named parameters in other languages.
I don't think any of your points are downsides to the proposal. A lot
of these I think boil down to the conflict between, "as an API user, I
should be able to do whatever I want", and, "as an API author, I have
decided my API will be used like this". I generally side with the API
author being specific on how their API will be used.
I think this is the same argument people have over the strict_types
declaration: should a library be able to constrain how users write their
code, even if it makes no difference to how the library functions?
With strict_types=0, a user can ask the language to convert a string to
an int on-the-fly, and a library author gets the int they asked for.
Similarly, named parameters allow users to call a function with
arguments in the "wrong" order, but the library author is guaranteed
they'll all be there. You could put partial application in the same
category: it allows a user to reuse your function without specifying all
the parameters each time!
Ultimately, even if the language didn't provide mechanisms for any of
these things, a user could write a wrapper that did. I'm not aware of a
programming language where libraries have the power to stop that, and I
think making it easier is a Good Thing: it allows users to reuse each
other's code, but adapt it to their own coding style.
If a function/method has labels, you're required to use them.
Otherwise, you can't get the benefit of using them for name-based
"overloading".
This is why I said earlier that I think Smalltalk-style function naming
is solving a different problem from named parameters. Smalltalk was
explicitly trying to make programming read like natural sentences, and
it used these multi-part names as a way to do that. That's a really
interesting concept, but it's not the feature that people are asking for
in PHP. And the restriction it places on how functions are called
directly works against solving the problems that named parameters would
solve.
Because there's generally only a few "correct" ways to word most sentences.
In that regard, AMQP::queue_declare is a pathological exception. There may be a good
reason for its specific order, but lacking that knowledge, it appears
to be completely arbitrary and nonintuitive.
It may be a "pathological exception" if you define the problem as "how
can we make methods read more like sentences"; but that's not the
problem I see named parameters as solving. The way I see it, requiring a
specific order for those parameters is itself an arbitrary constraint.
An example that's come up frequently in the thread is constructing
simple data objects. The actual requirement is "provide
appropriately-typed values for these N named fields"; in many cases,
there is no "natural order", and no particular value in the library
author choosing an order, *except that the language forces them to*.
Internally, the compiler / runtime needs everything to have an address
in linear memory; but humans like to give things names.
Rather than:
function strpos(string $1, string $2, int $3) { ... }
We prefer to define:
function strpos(string $haystack, string $needle, int $offset) { ... }
Within the body, we don't have to worry about the position of $haystack
and $needle in memory, we just use their names.
Named parameters are in a way just an extension of that; rather than:
strpos("hello", "l", 3)
We can write:
strpos(haystack: "hello", needle: "l", offset: 3)
Or:
strpos(needle: "l", haystack: "hello", offset: 3)
The order of parameters is no longer relevant; we've given them names,
and the compiler can sort out where they need to live in memory.
If I said to someone, "language the hard improve working We constantly
PHP to are", they'd probably look at me funny. We don't accept people
speaking human language with randomized word order; neither should API
authors (or other developers) be expected to accept people using APIs
with randomized parameter orders.
I you typed that into a special accessibility aid, and it was
automatically translated into the correct order by predictable rules
before I saw it, I a) wouldn't even know; and b) would be happy you were
able to use that aid to communicate with me.
Similarly, if you write a function and somebody can call it using their
preferred style that still guarantees the signature is followed, that's
a win for everyone.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
