Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Named arguments are coming in PHP 8

stitcher.io

Post reply on HN
Print view View original

11–20 of 140 posts

Re: Named arguments are coming in PHP 8

#11

Post by iso8859-1 »

thaumaturgy wrote: post #7

I'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…

You can have typed dictionaries too, even in a language similar to PHP: https://mypy.readthedocs.io/en/stable/more_types.html#typedd...

But anyway, I'd prefer anonymous records like in F#. There's no reason to have static and dynamic mappings have the same syntax, especially if they're not the same to the type checker, even a compiler could statically dispatch the static variant. So I agree with you that dicts are overused.

Re: Named arguments are coming in PHP 8

#12

Post by webignition »

arcosdev wrote: post #9
Aeolun wrote: post #8

Earlier 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?

I'd think that such a solution doesn't solve but merely moves the problem.

A method with N arguments, where N > 2, with a call that is messy due to the number of arguments could instead take a single argument being a parameter object where the constructor for the parameter object takes the same N arguments.

A constructor with N arguments with a call that is messy due to the number of arguments ...

Re: Named arguments are coming in PHP 8

#13

Post by stinos »

thaumaturgy wrote: post #7

I'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…

who want ... and many deeply-nested complex class hierarchies

Are there really people aiming for that, as a goal? Or is it rather just the result of large-scale software? And/or if it's really complex, then perhaps that's just the result of suboptimal design, not the intent?

Re: Named arguments are coming in PHP 8

#14

Post by throwaway43234 »

hprotagonist wrote: post #2

in 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 understand that it sort-of relates to declaring variadic arguments, but it certainly isn't declaring variadic arguments, and in my opinion reusing the same token in the same syntactic construct for two wildly different purposes is destined to cause confusion. For evidence, see the other replies: people don't know about this and can't easily tell what it does. This runs counter to the Zen: "Readability counts", "Explicit is better than implicit", "Special cases aren't special enough to break the rules.", etc.

I think JavaScript got this right where the semantic resolution steps of arguments pretty closely follow the steps for assignment, which means once someone understands the basic idea of object destructuring they get named arguments for free, in the form of destructured object parameters:

    const foo = (positionalArg1, {namedArg1, namedArg2 = 'foo'}) => { ... }
    foo(1, {namedArg: 'bar'}) 
    // resolved same as 
    const [positionalArg1, {namedArg, namedArg2 = 'foo'}] = [1, {namedArg: 'bar'}]

Re: Named arguments are coming in PHP 8

#15

Post by zerocrates »

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 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 would be in order rather than just silent acceptance of the variance combined with a hard error.

Re: Named arguments are coming in PHP 8

#16

Post by stareatgoats »

flemhans wrote: post #10
arcosdev wrote: post #9

Earlier quoted context omitted.

Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?

That's what the above comment was referring to when saying people to things like: call_user_func_array($function, ['length' => $n, 'foo' => $bar, ...]);

> and basically nobody does that anyway.

That's it, I'm officially a nobody :-)

Re: Named arguments are coming in PHP 8

#17

Post by kabacha »

throwaway43234 wrote: post #14
hprotagonist wrote: post #2

in 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…

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.

Re: Named arguments are coming in PHP 8

#18

Post by jakear »

kabacha wrote: post #17
throwaway43234 wrote: post #14

Earlier quoted context omitted.

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…

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 cases is quite a lot more logically clean & beautiful than introducing new syntax that other HN commenters with past python experience can’t even understand. If someone sees the JS named parameter syntax at a declaration and has any JS experience, they’ll almost certainly figure out what to do - if someone sees the asterisk, even with Python experience, they’ll think “what the heck is this asterisk?” And again, the other commenters on this thread are clear evidence that this is indeed as unintuitive as I describe.

Re: Named arguments are coming in PHP 8

#19

Post by sildur »

stareatgoats wrote: post #16
flemhans wrote: post #10

Earlier quoted context omitted.

That's what the above comment was referring to when saying people to things like: call_user_func_array($function, ['length' => $n, 'foo' => $bar, ...]);

> and basically nobody does that anyway. That's it, I'm officially a nobody :-)

> leaves it up to the called function to sanity-check the input types instead of letting the compiler do it, and basically nobody does that anyway.

You don’t check the input types?

Re: Named arguments are coming in PHP 8

#20

Post by flukus »

stinos wrote: post #13
thaumaturgy wrote: post #7

I'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…

who want ... and many deeply-nested complex class hierarchies Are there really people aiming for that, as a goal? Or is it rather just the result of large-scale software? And/or if it's really complex, then perhaps that's just the result of suboptimal design, not the intent?

Yes, sort of. There are many people that think of OOP as the goal and not the tool, that a more OOP solutions is better. Some of them equate complex class hierarchies with a job well done.

I'm being a bit hyperbolic, but I've worked that think a if/switch statements are a code smell that should be converted to complex class hierarchies.

Post reply on HN