Named arguments are coming in PHP 8 • Hacker News Board

Re: Named arguments are coming in PHP 8

#111

Post by gremlinsinc » Mon, Jul 27, 2020, 1:39 PM UTC

It feels like an anti-pattern, but I've been burned so many times by forgetting what order things go in, and not wanting to waste the 10 seconds to go look, that in a lot of methods if I have more than 2 parameters, I'll convert it to an array.

the associative array, thus giving me the named attributes.

It's a bit hackety, but the new named params looks like a much more elegant solution.

One issue also is if you have a method that takes 3 arguments and the 2nd is an integer not a string, and you pass a string you'll get an error... using an array, you can just test if the array key exists or not, and skip functionality as dictates by what's passed in.

Re: Named arguments are coming in PHP 8

#112

Post by mkopinsky » Mon, Jul 27, 2020, 1:41 PM UTC

hnarn wrote: post #81

> named arguments allow you to pass input data into a function, based on their argument name instead of the argument order Granted, I'm not a PHP developer, but I can't understand why a change like this would be controversial. It sounds like it's optional, and would help greatly to reduce mistakes when passing arguments to functions? Having multiple lines of things being passed to a function may look odd to some, but…

It's optional for the caller, but not for the callee. I think the controversy centers around two things:

a) Specific to this feature: For library maintainers, this means that argument names are now part of the public API, whether I like it or not, and renaming a parameter from $orderBy to $sortBy is now technically a breaking change. Yeah, you can put something in the readme saying "Heads up: I don't support named arguments and intend to rename arguments in semver-minor releases", but should you need to do that?

b) General to all new PHP features: PHP is a great language, with lots of crap code written in it. Will this feature result in people writing better or worse code? Just because something is optional doesn't mean it's a good idea, if it will result in the overall code quality of the ecosystem to get worse. Some people think that named arguments will make it too easy to create monster functions with too many parameters.

I personally support (aka am DELIGHTED by) named arguments, but I'm sympathetic to the concerns of library maintainers and I don't see a better way around it than a remark in the readme (at least until/unless they introduce e.g. a @@NoNamedArguments annotation in PHP 8.1). And I think that the benefits of named arguments far surpass the risk that they encourage people to create methods with too many arguments. But I can see both arguments.

Re: Named arguments are coming in PHP 8

#113

Post by gremlinsinc » Mon, Jul 27, 2020, 1:42 PM UTC

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 do this all the time, but it feels wrong... and you don't get type checking, this feels like it makes more sense and logical.

Re: Named arguments are coming in PHP 8

#114

Post by pansa2 » Mon, Jul 27, 2020, 1:42 PM UTC

detaro wrote: post #87

pansa2 wrote: post #40

Earlier quoted context omitted.

> There's a tension in PHP-land between [...] hobbyist-hacker [vs] enterprise-scale IMO the same tension exists in Python. The hobbyist-hackers are using the language to write small-ish scripts, and the enterprise-scale developers are working on million-line codebases. Unfortunately for the hobbyist-hackers, at some point (perhaps when the BDFL started working at Dropbox), the focus of the language shifted from the f…

That many developers never use type annotations (nothing interesting has happened to the type system in a long time) kind of suggests that it's not a problem. The feature is there if you want it, if you don't you ignore it.

Type annotations aren't entirely optional, though. For example, they're required if you want to use data classes.

Even if they were optional, that would still be a problem. As above, too many optional features are turning Python into a "choose your own subset" language like C++.

Re: Named arguments are coming in PHP 8

#115

Post by gremlinsinc » Mon, Jul 27, 2020, 1:47 PM UTC

Lammy wrote: post #36

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?

You can get the best of both approaches in PHP 5.6 or later using the argument unpacking "..." operator that works similarly to the */"splat" operator in Python or Ruby: https://www.php.net/manual/en/migration56.new-features.php

it's not the best of both worlds though, splat should only be used on something where you're basically doing the same thing to a bunch of things.

like add(1,2,3,4,5) ->

  function add(...$nums){
    $count = 0;
      foreach($nums as $num) { $count += $num; }
  }

If you know what arguments you're getting, then the more sound way would be just use an associative array, but either way you really don't get great type checking.

This is a much better solution.

Re: Named arguments are coming in PHP 8

#116

Post by pansa2 » Mon, Jul 27, 2020, 1:55 PM UTC

echelon wrote: post #41

tonyedgecombe wrote: post #31

Earlier quoted context omitted.

I think that post Python 3 nobody is going to do that. It would be interesting to see a fork which removed all the crud though. Something that was easy to use for the person doing occaisional web work or beginner but without the traps and pitfalls.

Python 3 attempted too much change at once. The Python folks could have spread incremental rollout of the changes across several major version numbers and probably not have faced such slow adoption.

> Python 3 attempted too much change at once.

Python 3 got this so, so wrong. It changed enough to break everyone's code, but not enough to make upgrading worthwhile.

It could have changed more, or changed less - done right, either would have been better than what actually happened.

Re: Named arguments are coming in PHP 8

#117

Post by spaetzleesser » Mon, Jul 27, 2020, 1:59 PM UTC

mkopinsky wrote: post #112

hnarn wrote: post #81

> named arguments allow you to pass input data into a function, based on their argument name instead of the argument order Granted, I'm not a PHP developer, but I can't understand why a change like this would be controversial. It sounds like it's optional, and would help greatly to reduce mistakes when passing arguments to functions? Having multiple lines of things being passed to a function may look odd to some, but…

It's optional for the caller, but not for the callee. I think the controversy centers around two things: a) Specific to this feature: For library maintainers, this means that argument names are now part of the public API, whether I like it or not, and renaming a parameter from $orderBy to $sortBy is now technically a breaking change. Yeah, you can put something in the readme saying "Heads up: I don't support named ar…

a) is a good point. I often rename parameters after a while to have more precise meaning. But I guess the advantages of named parameters outweigh the potential drawbacks.

Re: Named arguments are coming in PHP 8

#118

Post by spaetzleesser » Mon, Jul 27, 2020, 2:01 PM UTC

raxxorrax wrote: post #52

skocznymroczny wrote: post #48

Named arguments is a no-brainer for me for any kind of programming language. I am hoping D adopts named arguments too, although it's a very uphill battle there with many programmers coming from C/C++ background being opposed to it in the name of API stability.

I agree, it is a sensible improvement. What I don't like is spread operators in every form, but I can certainly live without funcy(null, null, null, null, null, null, cake, null, lie)...

I remember when dealing with Excel COM having lists of 30 arguments and more. And it made a difference if parameter 26 or parameter 27 was null.

Re: Named arguments are coming in PHP 8

#119

Post by rglullis » Mon, Jul 27, 2020, 2:16 PM UTC

pansa2 wrote: post #102

rglullis wrote: post #75

Earlier quoted context omitted.

You'd have a point if there were any changes that are being introduced and putting developers on a straight-jacket. But I don't see this tension at all. What is recent on Python3 that makes it hostile to hobbyists? The new features are optional, it's not like Python is forcing people to adopt mypy.

> What is recent on Python3 that makes it hostile to hobbyists? Python has become a very complex language [0], and the complexity continues to increase. IMO it's too much for people who only write code for, say, a few hours a week. > The new features are optional I hope Python isn't becoming a "choose your own subset" language like C++. [0] https://twitter.com/raymondh/status/1280946969116995584

The tweet shows a clear list of features (aside from the walrus operator) that are "complex" because they deal with inherit complexity. People who write code only for a few hours a week don't need to deal with asyncio or parallel programming, typing, cython, etc, etc.

The point about different frameworks and ecossytem is a strawman. Yes, it's large. No, it doesn't mean that is complex. No, you don't need to know all of it.

> I hope Python isn't becoming a "choose your own subset" language like C++

You are implying that are what is being added to the language have overlapping functionality. You really need a better argument than a FUD-y tweet to justify your concerns.

Re: Named arguments are coming in PHP 8

#120

Post by gregmac » Mon, Jul 27, 2020, 2:19 PM UTC

beberlei wrote: post #22

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…

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

Not just beginners. Seeing the following in a pull request is bad for everybody:

    someFunction(username, true, false, 10)

Named parameters remove ambiguity and make the code easier to read and review, and even avoid bugs because if you're passing the wrong values it's immediately obvious.

One of the hidden issues with the above code comes in the future: if anyone ever changes the order of the 2nd and 3rd arguments in the function definition, and forgets to update this spot, the code will still "work" (no compile error) but instead will have the wrong runtime behaviour. In a pull request, you can't see all the affected spots that didn't get updated, so it is easy to slip through.