Live data from Hacker News

What PHP 5.5 might look like

nikic.github.com

1–10 of 139 posts

Re: What PHP 5.5 might look like

#2
Pretty exciting, though empty() should be deprecated, not improved upon.

The bit about getting the fully qualified class name is important, but it still prevents you from doing something like:

  function builder_factory( $var ) {
    $class = $some_array[ $var ];

    return new $class();
  }
So you have to write a ton of boilerplate for something that used to be easy without namespaces, or write namespace traversal into your PHP (which isn't THAT hard, but is very ugly).

Parameter skipping looks intuitive and useful. Very important as we incorporate more functional paradigms into the code.

I don't believe scalar type hinting will make it in. There's just too much discussion around it. IMHO, it should be super strict. "1" is not an integer.

Getters and setters: meh. I guess it's good. Better than what we have now.

I don't believe PHP will do generators or list comprehensions right, so I'm not holding my breath on those.

Re: What PHP 5.5 might look like

#3
Consistency in dereferencing is very important. empty() should at some point be deprecated, but fixing this erratic behavior for now is good imo.

The default value for method arguments is a shockingly bad idea for a new feature, it only supports the old, bashed upon, code quality that have been PHPs greatest legacy problem. If anything in this alley I'd like to see named arguments somehow.

I'm not so sure about property getter/setters as I find the syntax a bit awkward, all while magic methods lets you create getter/setter based APIs.

Re: What PHP 5.5 might look like

#4
post #2

Pretty exciting, though empty() should be deprecated, not improved upon. The bit about getting the fully qualified class name is important, but it still prevents you from doing something like: function builder_factory( $var ) { $class = $some_array[ $var ]; return new $class(); } So you have to write a ton of boilerplate for something that used to be easy without namespaces, or write namespace traversal into your PHP…

Better than parameter skipping would be named parameters so you could just do:

    function foo($a, $b="10", $c="5", $d="3") { /* .. */ }

    foo(5, $c="10");
That way $a == 5, $b == "10", $c == "10", and $d == "3". Much better and cleaner syntax in my opinion and a lot of other languages support something similar.

Re: What PHP 5.5 might look like

#5
post #4
post #2

Pretty exciting, though empty() should be deprecated, not improved upon. The bit about getting the fully qualified class name is important, but it still prevents you from doing something like: function builder_factory( $var ) { $class = $some_array[ $var ]; return new $class(); } So you have to write a ton of boilerplate for something that used to be easy without namespaces, or write namespace traversal into your PHP…

Better than parameter skipping would be named parameters so you could just do: function foo($a, $b="10", $c="5", $d="3") { /* .. */ } foo(5, $c="10"); That way $a == 5, $b == "10", $c == "10", and $d == "3". Much better and cleaner syntax in my opinion and a lot of other languages support something similar.

I agree, named parameters are useful as well, but there's no reason that both shouldn't be implemented.

The problem with PHP is that, due to the nature of the interpreter, so many of these things are written as syntactical sugar which means that their implementations usually leave much to be desired.

Re: What PHP 5.5 might look like

#6
The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as:

  $names = array_column($users, 'name');
  // is the same as
  $names = [foreach ($users as $user) yield $user['name']];
The only possible reason would be due to a significant speed difference, but I'd suggest improving the efficiency of the list comprehension system (even if just for common cases) than adding more functions.

As opposed to the introduction of list comprehensions, I can't say I like the solution for parameter skipping though... I disagree with the author -- many optional arguments is not a problem, but only if keyword arguments or a similar style are used. Consider the example they give:

  // This create query function in PHP
  create_query("deleted=0", "name", default, default, false);
  // could be represented like this with keyword arguments
  create_query("deleted=0", "name", escape_arguments=false)
I tend to find keyword arguments serve the purpose of self documentation as well -- I still have no clue what the false flag would be for the PHP create_query statement.

Keyword arguments and many optional arguments can allow for beautiful and flexible functions, such as the Python Requests library[1].

  r = requests.get('https://api.github.com/xyz')
  # or we could add a few more complications
  # -- no "defaults" in sight and also self documenting
  r = requests.get('https://api.github.com/xyz',
    auth=('user', 'pass'), timeout=0.5, allow_redirects=True)
[1]: http://docs.python-requests.org/

Re: What PHP 5.5 might look like

#7

Consistency in dereferencing is very important. empty() should at some point be deprecated, but fixing this erratic behavior for now is good imo. The default value for method arguments is a shockingly bad idea for a new feature, it only supports the old, bashed upon, code quality that have been PHPs greatest legacy problem. If anything in this alley I'd like to see named arguments somehow. I'm not so sure about prope…

What's the deal with empty()? I've never used it myself but found people at the new place I work do use it.

Re: What PHP 5.5 might look like

#8
post #7

Consistency in dereferencing is very important. empty() should at some point be deprecated, but fixing this erratic behavior for now is good imo. The default value for method arguments is a shockingly bad idea for a new feature, it only supports the old, bashed upon, code quality that have been PHPs greatest legacy problem. If anything in this alley I'd like to see named arguments somehow. I'm not so sure about prope…

What's the deal with empty()? I've never used it myself but found people at the new place I work do use it.

Like the article said, you can't use it with function calls because empty() itself is a construct of the language and not a function. So, empty(someFunc()) is an error. You'd have to put the return value of someFunc() in a variable and test it for emptiness, or do something like if (0 == strlen(someFunc())) { /* .. */ } which is overly verbose and not fast.

Re: What PHP 5.5 might look like

#9
post #7

Consistency in dereferencing is very important. empty() should at some point be deprecated, but fixing this erratic behavior for now is good imo. The default value for method arguments is a shockingly bad idea for a new feature, it only supports the old, bashed upon, code quality that have been PHPs greatest legacy problem. If anything in this alley I'd like to see named arguments somehow. I'm not so sure about prope…

What's the deal with empty()? I've never used it myself but found people at the new place I work do use it.

[deleted]

Re: What PHP 5.5 might look like

#10
No matter how much PHP is improved upon, until there is a serious contender framework for it like Rails or Django, PHP will continue its route to extinction. Dinosaurs were once big and powerful. They dominated the landscape. They don't exist anymore.
Post reply on HN