It's beginning to look a lot like -- typescript
Named arguments are coming in PHP 8
21–30 of 140 posts
Re: Named arguments are coming in PHP 8
#22I'm ambivalent. There's a tension in PHP-land between PHP's roots as a low-ish level, get-it-done, hackish language, with its big standard library and simple scalar types, and the better-organized and quite vocal developers who want it to be more Java-like, with great big frameworks and many deeply-nested complex class hierarchies. Instead of unwieldy hobbyist-hacker balls of mud, you build enterprise-scale balls of…
Named params helps the beginners, maybe even more for use of internal APIs
- no needle/haystack order problems anymore - no need going to docs to understand what a boolean or „magic value“ stands for
Re: Named arguments are coming in PHP 8
#23Earlier quoted context omitted.
> break the function signature into one-line-per-parameter, which is vile Speak for yourself. If each line indicates what it is the parameter for I couldn’t care less. Nobody will use this for functions that have just two parameters. It’s the ones that have 10 possibilities that are crazy.
Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?
That is possible, but requires writing a class, which increases mental load
Re: Named arguments are coming in PHP 8
#24Earlier quoted context omitted.
It‘s a separator between positional and keywords. It’s * because the “rest” argument (*args) also makes following arguments keyword-only, so a lone star is essentially one which collects nothing.
So this requires the following args to be named? Neat!
Yes.
For python-level functions initially all arguments could be passed either positionally or by keyword, unless they slotted into the special `∗args` (positional-only) or `∗∗kwargs` (keyword-only) parameters (note: the star-prefixes is the important part here the names can be anything).
Now I'm saying this was for python-level functions because (AFAIK) at the C level it was always possible to rather easily define positional-only or keyword-only arguments.
Anyway one of the improvements of Python 3 was to allow parameters other than `∗∗kwargs` after `∗args`, with the effect of making them individually named but keyword-only (PEP 3102). A logical extension of the same was to allow keyword-only arguments without any positional, that's what the `*` pseudo-argument defines:
> The reasoning behind this change is as follows. Imagine for a moment a function which takes several positional arguments, as well as a keyword argument.
> Now, suppose you wanted to have 'key' be a keyword-only argument. Under the above syntax, you could accomplish this by adding a varargs (nb: `∗ignore`) argument immediately before the keyword argument.
> Unfortunately, the 'ignore' argument will also suck up any erroneous positional arguments that may have been supplied by the caller. Given that we'd prefer any unwanted arguments to raise an error, we could do this (nb: add an explicit assertion that `ignore` is empty)
> As a convenient shortcut, we can simply omit the 'ignore' name, meaning 'don't allow any positional arguments beyond this point'.
Re: Named arguments are coming in PHP 8
#25Earlier quoted context omitted.
I'll disagree with you here. In Python `*` is already a extremely popular symbol for expanding and there's no usage conflict between expand and numeric multiplication. This change gels really nicely with the rest of expand ecosystem. I think it's much more beautiful and convenient than your JS example which in all honesty looks necessary cluttered and ugly.
But there’s no expanding happening here? So why take a token that’s immediately recognizable as either “expanding” or “muliplying-ish” and extend it to mean “or enforcing named parameters and not expanding”? > cluttered and ugly I won’t argue with you about visuals because I don’t think they’re all that important. But, I think it’s undeniable that reusing the same syntactic concepts across different semantic use case…
> But there’s no expanding happening here?
There's a collection of 0 arguments. the "∗" was introduced specifically as a shortcut for:
def foo(a, *ignore, b):
if ignore:
raise TypeError
It's a logical extension of the assumption that anything which follows `∗arg` is a keyword-only parameter.
Re: Named arguments are coming in PHP 8
#26in python i started writing any function that takes >2 arguments as either def foo(*,a,b,c)... or def foo(obvious_and_required_thing, *, a,b,c) ... and noticed an immediate improvement in clarity.
I understand that this is standard practice by now, but this is one of those cases where I can't help but feel the language design team strayed too far from the original spirit of python. Now there's yet another possible interpretation of an asterisk: multiplication; splatting; exponentiation; declaring variadic arguments; and now declaring that all subsequently declared arguments are to be keyword-only. And I unders…
> This runs counter to the Zen: "Readability counts", "Explicit is better than implicit"
Huh? It's both making parameters more explicit and functions using it more readable and self-documenting.
In fact, the old way, before bare / and * in args list, where functions essentially had mandatory optional-keyword arguments made every function create an API in violation of “There should be one-- and preferably only one --obvious way to do it.”
Re: Named arguments are coming in PHP 8
#27I always wonder why PHP never seems to favour making breaking changes to keep things cleaner, if you aren't going to improve language constructs in a major version, when will they be cleaned up?
Re: Named arguments are coming in PHP 8
#28Earlier quoted context omitted.
I'll disagree with you here. In Python `*` is already a extremely popular symbol for expanding and there's no usage conflict between expand and numeric multiplication. This change gels really nicely with the rest of expand ecosystem. I think it's much more beautiful and convenient than your JS example which in all honesty looks necessary cluttered and ugly.
But there’s no expanding happening here? So why take a token that’s immediately recognizable as either “expanding” or “muliplying-ish” and extend it to mean “or enforcing named parameters and not expanding”? > cluttered and ugly I won’t argue with you about visuals because I don’t think they’re all that important. But, I think it’s undeniable that reusing the same syntactic concepts across different semantic use case…
*args
*
They are close enough cognitively to warrant reuse IMO.
Re: Named arguments are coming in PHP 8
#29I get why it's being done that way, but the bit about parameter names being allowed to vary in subclasses feels... non-great. As a result you can't really safely use named parameters on calls without more extensive control of what you're being passed: even if you typehint to a class or interface, you can just get passed a parameter-name-changed subclass that breaks your call anyway. Feels like a "strict" type warning…
> I get why it's being done that way, but the bit about parameter names being allowed to vary in subclasses feels... non-great.
As justified, it feels necessary for backwards-compatibility reasons since named arguments are not defined as named, just used as such.
Re: Named arguments are coming in PHP 8
#30Earlier quoted context omitted.
> break the function signature into one-line-per-parameter, which is vile Speak for yourself. If each line indicates what it is the parameter for I couldn’t care less. Nobody will use this for functions that have just two parameters. It’s the ones that have 10 possibilities that are crazy.
Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?
With a dictionary (array in PHP) you lose strict typing and it's possible for the person constructing it to make a typo and it won't cause an error, the called function will just think an optional argument was left out.
Writing and maintaining parameter classes is just tedious.