12 ms·

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 s

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 mud. Named arguments don't do a lot for the first group. It looks like the big point in favor is not having to look up a reference for which-arguments-go-where in functions anymore, but a good IDE already does that for you. But there is a common anti-pattern where you have some polymorphic function or interface, and you want to accrete your arguments somewhere and then bundle them up and call the function, so then you see things like [1]: call_user_func($function, ['length' => $n, 'foo' => $bar, ...]); ...and that is bad because it totally bypasses all of PHP's type-checking and 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. So named parameters would fix that at least, which would be nice. I'm just not looking forward to the impact this is going to have on code readability, because everyone (including this article) is going to go, "oh, now my parameter list is too long!", and break the function signature into one-line-per-parameter, which is vile. [1]: I'm guilty of this too.

Aeolun 6y ago
> 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.
- arcosdev 6y ago
  Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?
  - flemhans 6y ago
    That's what the above comment was referring to when saying people to things like: call_user_func_array($function, ['length' => $n, 'foo' => $bar, ...]);
    - stareatgoats 6y ago
      > and basically nobody does that anyway. That's it, I'm officially a nobody :-)
      - sildur 6y ago
        > 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?
        stareatgoats 6y ago
        You're reading the sentence incorrectly: "and basically nobody does that anyway", means the preceding type checking argument you refer to is moot. So I insist, I am a nobody (according to this definition). Btw I don't always sanity check the parameters, mostly at the system edges only.
        z92 6y ago
        Not in get-it-done, hackish scripts.
  - webignition 6y ago
    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 ...
    - 6y ago
- waheoo 6y ago
  Other than plain object constructs these kinds of functions are unheard of and better handled with a parameter object or array. I can't help but feel if they just set up a clean way to name construct Params for classes this wouldn't need to happen.
  - raziel2p 6y ago
    Why are they better handled with a parameter object or array? https://news.ycombinator.com/item?id=23962955 https://news.ycombinator.com/item?id=23962955 What is the functional difference between a named construct "Params" and just allowing named parameters?
    - deleted 6y ago
      [deleted]
    - chriswarbo 6y ago
      > What is the functional difference between a named construct "Params" and just allowing named parameters? That "just" is doing a lot of work. I've not used PHP for a few years, but off the top of my head I can forsee the following problems: - `call_user_func` would need to change to support this, e.g. accepting and passing-along named parameters. - `call_user_func_array` would need to change, e.g. passing along associative-array arguments as named parameters. - `func_get_args` would need to change, e.g. returning an associative array Other parts of the standard library, like ReflectionParameter, would also need corresponding changes. On their own I don't think those are necessarily bad. However, this would break a lot of code which relies on those functions and their invariants. For example, currying and partial application would become more complicated (e.g. http://chriswarbo.net/blog/2014-02-21-partial_application___currying_in_php.html http://chriswarbo.net/blog/2014-02-21-partial_application___... ). I'm not necessarily against this change, but I would make the following points: Extending APIs is a breaking change, since it breaks invariants/contracts that previously held (in this case by function definitions and call sites). This breaks backwards-compatibility, and that should be acknowledged and stated explicitly, rather than ignored. Here's a quick example of code which breaks, since it relies on the now-violated invariant that the parameter order of a function call matches that of the definition: function call_with_strings() { $args = func_get_args(); $f = array_shift($args); $strings = []; foreach ($args as $arg) { $strings[] = strval($arg); } return call_user_func($f, $strings); } Secondly: there's a definite bandwagon effect between scripting languages like PHP/Python/JS/etc., for better (easier to transfer between) or worse (uncompelling monocultures lacking innovation/USP). Just because a feature exists in one, doesn't necessarily make it a good idea for the others (or the first, for that matter!); conversely, there are lots of great features out there which scripting languages don't seem to have picked up, and which are hardly ever brought up in these discussions. For example: - Default arguments are generally supported, e.g. `parseInt(i, base=10)`. Alternative approaches to the same problem, like currying, are mostly absent, e.g. `parseIntFor(base, i); parseInt = parseIntFor(10);` - Generators are generally supported, e.g. `for x in foo: yield x`. Alternative approaches to the same problem, like delimited continuations, are mostly absent, e.g. `reset; for x in foo: shift(x);`. This is especially interesting, since it's just an extension of exception handling, which is another generally-supported feature! - Named parameters are generally supported, e.g. `foo(a=1, c=5)`. Alternative approaches to the same problem, like row-polymorphism, are mostly absent, e.g. `foo(['a' => 1, 'c' => 5])`.
- masklinn 6y ago
  > Nobody will use this for functions that have just two parameters. It’s the ones that have 10 possibilities that are crazy. It can be super useful even for functions with low arity e.g. `max(seq, key=func)`.
- dariusj18 6y ago
  I'll use it for functions with two parameters, array functions and the order you pass in arguments is not standardized. I can start just using named functions to make it clear and easier to read/write.
iso8859-1 6y ago
You can have typed dictionaries too, even in a language similar to PHP: https://mypy.readthedocs.io/en/stable/more_types.html#typeddict 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.
stinos 6y ago
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?
- flukus 6y ago
  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.
  - cyphax 6y ago
    I can sympathize with that, but at the same time: the idea that the language and its OOP implementation is a tool rather than the goal, and the idea of improving said tool are not mutually exclusive. :) In my experiences with C#, things like named params have been nice, even if it's often just syntactic sugar; these things can be quality of life improvements for the programmer without changing anything about the goal.
beberlei 6y ago
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
- gregmac 6y ago
  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.
tannhaeuser 6y ago
> tension in PHP-land between PHP's roots as a low-ish level, get-it-done, hackish language [...] and the better-organized and quite vocal developers who want it to be more Java-like Agree, and I'd like to add the original purpose of PHP, and what made it popular in the first place was that it can be used as embedded PHP within SGML-ish processing instruction ie <!php ...>. Only that PHP made such a lousy hack job of it being not HTML-aware and not doing context-dependent escaping, that it would become the primary script injection/XSS attack vector on the web. PHP's forte IMHO is its community and the large installed base of apps (there doesn't exist anything like Magento with its first-party plugins by DHL, UPS, payment providers, etc on Node.js for example). Why PHP wants to become more like Java or JavaScript is a mystery for me, when there's a hell of a cleanup job to be done beforehand, such as fixing <?php ...>.
Lammy 6y ago
One-line-per-argument function signatures are nice for making clean diffs :)
pansa2 6y ago
> 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 first group to the second. That's why, for example, Python now has a complex type system - that many developers never use.
- oaiey 6y ago
  I would argue that has a strong correlation with the fact that universities are now teaching Python instead of Java. Once that alumni hits the job market, hobbyist-hackers are no longer the majority of users.
- rglullis 6y ago
  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.
  - pansa2 6y ago
    > 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 https://twitter.com/raymondh/status/1280946969116995584
    - rglullis 6y ago
      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.
deleted 6y ago
[deleted]
coldtea 6y ago
>Named arguments don't do a lot for the first group. It looks like the big point in favor is not having to look up a reference for which-arguments-go-where in functions anymore, but a good IDE already does that for you. I, for one, never particularly liked this last argument.

Aeolun 6y ago

> 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.

arcosdev 6y ago
Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?
- flemhans 6y ago
  That's what the above comment was referring to when saying people to things like: call_user_func_array($function, ['length' => $n, 'foo' => $bar, ...]);
  - stareatgoats 6y ago
    > and basically nobody does that anyway. That's it, I'm officially a nobody :-)
    - sildur 6y ago
      > 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?
      - stareatgoats 6y ago
        You're reading the sentence incorrectly: "and basically nobody does that anyway", means the preceding type checking argument you refer to is moot. So I insist, I am a nobody (according to this definition). Btw I don't always sanity check the parameters, mostly at the system edges only.
      - z92 6y ago
        Not in get-it-done, hackish scripts.
- webignition 6y ago
  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 ...
  - 6y ago
waheoo 6y ago
Other than plain object constructs these kinds of functions are unheard of and better handled with a parameter object or array. I can't help but feel if they just set up a clean way to name construct Params for classes this wouldn't need to happen.
- raziel2p 6y ago
  Why are they better handled with a parameter object or array? https://news.ycombinator.com/item?id=23962955 https://news.ycombinator.com/item?id=23962955 What is the functional difference between a named construct "Params" and just allowing named parameters?
  - deleted 6y ago
    [deleted]
  - chriswarbo 6y ago
    > What is the functional difference between a named construct "Params" and just allowing named parameters? That "just" is doing a lot of work. I've not used PHP for a few years, but off the top of my head I can forsee the following problems: - `call_user_func` would need to change to support this, e.g. accepting and passing-along named parameters. - `call_user_func_array` would need to change, e.g. passing along associative-array arguments as named parameters. - `func_get_args` would need to change, e.g. returning an associative array Other parts of the standard library, like ReflectionParameter, would also need corresponding changes. On their own I don't think those are necessarily bad. However, this would break a lot of code which relies on those functions and their invariants. For example, currying and partial application would become more complicated (e.g. http://chriswarbo.net/blog/2014-02-21-partial_application___currying_in_php.html http://chriswarbo.net/blog/2014-02-21-partial_application___... ). I'm not necessarily against this change, but I would make the following points: Extending APIs is a breaking change, since it breaks invariants/contracts that previously held (in this case by function definitions and call sites). This breaks backwards-compatibility, and that should be acknowledged and stated explicitly, rather than ignored. Here's a quick example of code which breaks, since it relies on the now-violated invariant that the parameter order of a function call matches that of the definition: function call_with_strings() { $args = func_get_args(); $f = array_shift($args); $strings = []; foreach ($args as $arg) { $strings[] = strval($arg); } return call_user_func($f, $strings); } Secondly: there's a definite bandwagon effect between scripting languages like PHP/Python/JS/etc., for better (easier to transfer between) or worse (uncompelling monocultures lacking innovation/USP). Just because a feature exists in one, doesn't necessarily make it a good idea for the others (or the first, for that matter!); conversely, there are lots of great features out there which scripting languages don't seem to have picked up, and which are hardly ever brought up in these discussions. For example: - Default arguments are generally supported, e.g. `parseInt(i, base=10)`. Alternative approaches to the same problem, like currying, are mostly absent, e.g. `parseIntFor(base, i); parseInt = parseIntFor(10);` - Generators are generally supported, e.g. `for x in foo: yield x`. Alternative approaches to the same problem, like delimited continuations, are mostly absent, e.g. `reset; for x in foo: shift(x);`. This is especially interesting, since it's just an extension of exception handling, which is another generally-supported feature! - Named parameters are generally supported, e.g. `foo(a=1, c=5)`. Alternative approaches to the same problem, like row-polymorphism, are mostly absent, e.g. `foo(['a' => 1, 'c' => 5])`.
masklinn 6y ago
> Nobody will use this for functions that have just two parameters. It’s the ones that have 10 possibilities that are crazy. It can be super useful even for functions with low arity e.g. `max(seq, key=func)`.
dariusj18 6y ago
I'll use it for functions with two parameters, array functions and the order you pass in arguments is not standardized. I can start just using named functions to make it clear and easier to read/write.

iso8859-1 6y ago

You can have typed dictionaries too, even in a language similar to PHP: https://mypy.readthedocs.io/en/stable/more_types.html#typeddict 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.

stinos 6y ago

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?

flukus 6y ago
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.
- cyphax 6y ago
  I can sympathize with that, but at the same time: the idea that the language and its OOP implementation is a tool rather than the goal, and the idea of improving said tool are not mutually exclusive. :) In my experiences with C#, things like named params have been nice, even if it's often just syntactic sugar; these things can be quality of life improvements for the programmer without changing anything about the goal.

beberlei 6y ago

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

gregmac 6y ago
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.

tannhaeuser 6y ago

> tension in PHP-land between PHP's roots as a low-ish level, get-it-done, hackish language [...] and the better-organized and quite vocal developers who want it to be more Java-like Agree, and I'd like to add the original purpose of PHP, and what made it popular in the first place was that it can be used as embedded PHP within SGML-ish processing instruction ie <!php ...>. Only that PHP made such a lousy hack job of it being not HTML-aware and not doing context-dependent escaping, that it would become the primary script injection/XSS attack vector on the web. PHP's forte IMHO is its community and the large installed base of apps (there doesn't exist anything like Magento with its first-party plugins by DHL, UPS, payment providers, etc on Node.js for example). Why PHP wants to become more like Java or JavaScript is a mystery for me, when there's a hell of a cleanup job to be done beforehand, such as fixing <?php ...>.

Lammy 6y ago

One-line-per-argument function signatures are nice for making clean diffs :)

pansa2 6y ago

> 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 first group to the second. That's why, for example, Python now has a complex type system - that many developers never use.

oaiey 6y ago
I would argue that has a strong correlation with the fact that universities are now teaching Python instead of Java. Once that alumni hits the job market, hobbyist-hackers are no longer the majority of users.
rglullis 6y ago
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.
- pansa2 6y ago
  > 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 https://twitter.com/raymondh/status/1280946969116995584
  - rglullis 6y ago
    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.

deleted 6y ago

[deleted]

coldtea 6y ago

>Named arguments don't do a lot for the first group. It looks like the big point in favor is not having to look up a reference for which-arguments-go-where in functions anymore, but a good IDE already does that for you. I, for one, never particularly liked this last argument.