Hacker News Reader

Comment by donatj | Hacker News Reader

Despite peoples grumblings about parameter order the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack. Once you know that its not that difficult.

Some other minor inconsistencies like array_map vs. array_filter are simply due to the fact that optional parameters have to be at the end of function calls. On array_filter the callback is optional, whereas on map you can map a list of arrays.

View on HN

Parameter order is an important part of a function's interface. In particular, commonly-used arguments should occur before call-site-specific arguments, so that we can specialise the function. array_map gets this right:

    $asBools = partial_apply('array_map', 'boolval');

    $asBools(['hello', '', 'world']) === [true, false, true]
    $asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true]

array_filter and array_reduce get this wrong, requiring awkward argument-shuffling:

    $inverseFilter = partial_apply(flip('filter'), 'boolNot');

    $inverseFilter([-2, -1, 0, 1, 2]) === [2 => 0]
    array_keys($inverseFilter(['foo' => true, 'bar' => false])) === ['bar']

    $allTrue = partial_apply(flip(partial_apply(flip('array_reduce'), 'boolAnd')), true);

    $allTrue(['hello', 'world']) === true
    $allTrue([true, true, 0, true]) === false

Note that a) if specialisation was easy, there would be no need for default arguments and b) having default arguments at the end is exactly the wrong way around for making specialisation not suck.

We could sweep this under the rug by saying it's awkward because it's not idiomatic PHP; but one reason why it's not idiomatic is that it's awkward!

Just look at Javascript, where functions are slightly less awkward; there are lots of functional APIs in wide use, eg. Underscore.

The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.

That's something I'm working on by adding function references. Not sure if it'll be accepted.

I feel like its callable system is simple, easy to use, and frankly awesome.

I can do $func = ['object', 'staticMethodName'];

$func = [$instance, 'publicMethodName'];

$func = 'functionName';

$func = '\namespaced\functionName';

$func = function(){ ... };

$func = $callableObject; // ( http://php.net/manual/en/language.oop5.overloading.php#objec... )

I can execute any of the above by calling `$func('doIt');`

Moreover all of those will all pass a `callable` typehint on a method call as well as the is_callable if they exist and are callable. Its quite powerful.

The problem is that a function is a thing. A string is a different thing. Imagine if arrays were represented as comma delimited strings, and you had a function isArray to check if a string has the right format to represent an array. That would be ridiculous right? An array should be its own type. The same goes for functions. Representing functions as string names is just as crazy as representing arrays as comma delimited strings.

Though who am I kidding, PHP is also confused between numbers and arrays and strings, so I guess at least it's consistent that the language is thoroughly crazy.

Ridiculous or not, Tcl works like this. Everything is a string.

A lot of languages have ways of calling functions and methods by string names -- PHP just makes it very easy and the design is actually really clean.

> PHP just makes it very easy and the design is actually really clean.

Very little about PHP's treatment of functions is easy or clean.

    function foo() { echo "Hello world"; }

    $w = 'foo';
    echo $w;  // foo
    $w();     // Hello world
    'foo'();  // PHP Parse error: syntax error, unexpected '('

    function bar() { return 'foo'; }
    $x = bar();
    echo $x;  // foo
    $x();     // Hello world
    bar()();  // PHP Parse error:  syntax error, unexpected '('

    $o = new stdClass;
    $o->baz = 'foo';
    $y = $o->baz;
    echo $y;  // foo
    $y();     // Hello world
    $o->baz();  // PHP Fatal error:  Call to undefined method stdClass::baz()

Heck, PHP doesn't even recognise function-call syntax applied to a function!

    $z = function() {
           echo "Hello world";
         };
    $z();  // Hello world
    (function() {
       echo "Hello world";
     })();  // PHP Parse error:  syntax error, unexpected '('

When this[1] RFC goes through most of those issues will be resolved. Even without them, ignoring edge cases ('foo'() isn't useful), it's still quite reasonable. The RFC linked above just improves on the design, it doesn't change it.

[1] https://wiki.php.net/rfc/uniform_variable_syntax

> the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack

There's a trick to this that isn't too hard to remember. Searching for a value in an array is much more akin to searching for a needle in a haystack.

So, for array functions, it's like searching for a needle in a haystack. For string functions, you're searching in a haystack for a needle.

I'm not really commenting on whether one should have to remember this, only that it helps if you need to remember it.

> searching for a needle in a haystack > searching in a haystack for a needle

wait, what's the difference?

The order of the words.

Reply on news.ycombinator.com