Hacker News Reader

> I'm not sure why they're adding the array_column function

Isn't the function call much more readable than the comprehension?

At least as a beginner, I found the large set of built in functions to be one of the strongest points of PHP.

One major disadvantage with so many functions is the cluttered global namespace[1]. PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace, I'd be wary of adding more. Mind you, I'm well aware that this feeling could just be as I'm primarily a Python coder -- in PHP, you perform array_keys($xyz) whilst in Python it's xyz.keys(). Whilst you might consider Python as cheating by pushing all the functions onto the objects, it results in a far happier global namespace[2].

As far as list comprehensions, I tend to find list comprehensions the readable and self documenting, at least in Python where I most commonly see them. If nothing else, what is the ordering of the arguments for the equivalent non list comprehension? With list comprehensions you don't have that impedance.

  // Python example with filter vs list comprehension
  // Filter requires you to remember the ordering --
  // and does it filter on True or False?
  filter(lambda x: x % 2 == 0, range(10)) --> 0 2 4 6 8
  // The list comprehension is self documenting
  [x for x in range(10) if x % 2 == 0] --> 0 2 4 6 8

I can also convert the majority of list comprehensions into English quite easily -- "output x for each x in range(10) if x is divisible by 2" (though it may be cleaner if it was "for each x in range(10) [output x] if x is divisible by 2").

[1]: http://php.net/quickref.php

[2]: http://docs.python.org/library/functions.html + http://docs.python.org/library/exceptions.html

Yes what the code does is very clear, but the function call is even a level up clearer, maybe you don't want to know how it does it's job, you just want an array of values in a column (array_column(array, column)). Personally I like comprehensions, but I tend to disguise them behind a function, it's much more clear to me. (but if I need the code to be super fast, I avoid using an extra function.)

>PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace

They could do what Python did for 3.0, and make a tool similar to Python's 2to3 that replaces global namespace references.

That sounds like a disaster. I don't think anyone wants to follow Python's lead on breaking backwards compatibility without a very good reason. A much better reason than a cluttered namespace.

If they're going to allow queries on arrays of lists -- not a bad idea -- why not simply implement a SQL subset? I can see a huge collection of new array functions...

Something like PHPlinq?

http://phplinq.codeplex.com/wikipage?title=Examples&refe...

I agree with you on using keyword arguments, it makes it more obvious (and where there are many optional parameters, may save some typing!).

With regards to the array_column function, PHP has a history of providing such functions for common operations, even where the same functionality can be replicated with more generic code constructs. For me, the function example you provide is more readable than the comprehension example, requires less typing and provides less room for mistakes. I.E. its simpler in this case, and that’s part of the way PHP rolls. There is of course an argument that functions like this should be provided by external libraries or frameworks rather than in the core of the language, but that debate has been had many times and PHP has come down on the side of including them. This is one of the reasons developers like me like PHP. YMMV.

Agreed on keyword args. I maintain Requests for PHP [1] which has a very similar API to Python Requests, and at the moment, you have to use an array as the options parameter.

    $options = ['timeout' => 0.5];
    $r = Requests::get('https://api.github.com/', $headers, $data, $options);

[1]: http://requests.ryanmccue.info/

I can't say I like the solution for parameter skipping though... I disagree with the author -- many optional arguments is not a problem

IMO This is a problem and bad design, because instead of default arguments you can use properties for optional arguments.

You can, but: some function already exist with existing APIs - especially in libraries and existing internal PHP functions - and currently there's no way to say "I want default for the second parameter, but non-default for the third", unless you copy-paste the default from the docs.

Or encapsulate excess arguments in objects that represent the data that needs to be moved around, if possible.

array_column looks like a half-assed version of map. Looks like PHP hasn't changed a bit. Functions that do half of what their supposed to do and have odd names that depart wildly from industry standard language.

> have odd names that depart wildly from industry standard language

Err... what? You want map, use map.

http://us3.php.net/manual/en/function.array-map.php

to be fair he did mention array_pluck, but the odds are for the most awkward name.

I agree keyword arguments are a better solution (but probably harder to implement).

Right now this is how I do this:

    function salute($user, array $options = null) {
        $options = (array) $options + array('shout' => false);
        $salutation = "Hi $user!";
        if ($options['shout']) $salutation = strtoupper($salutation);
        return $salutation;
    }

It is significantly harder to implement, especially if you think about what happens with existing functions, especially internal ones.

I, for one, never understood why there was no "default" keyword available, but the python example is great as well.

About the rest of the article :

- the modified empty() is nice, while I still think this function accepts to much thing as empty, or at least should be more flexible.

Getter/setter : finally. Now I don't get why there is no readonly keyword which would put the variable as readonly only for the class' outer world.

The article clearly states that there are more features like a read-only keyword.

https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

That's not what he's referring to. He's specifically referring to a read-only that only affects external classes. So, the object itself could write to that field, but nothing else could.

You can set the visibility of both the properties and the getters/setters.

    class Foo {
        private $fuzz;
        
        protected $Bar {
            get { return $this->fuzz; }
            private set { $this->fuzz = $value; }
        }
    }

Yes. I understand that.

My point was just that he specifically wanted a read-only.

I do not believe you can improve generic list comprehension/generator system to a level it would have the speed of a specialized C function, unless you make a special case in the compiler which would effectively call such function instead of actually generating the code as written.

Keyword args would make such a huge difference. +1 to that.