Hacker News Reader

Comment by debacle | Hacker News Reader

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.

View on HN

I'm curious: Why do you think empty() should be deprecated? Do you think the same of isset?

http://www.zachstronaut.com/posts/2009/02/09/careful-with-ph...

http://stackoverflow.com/questions/410002/fixing-the-php-emp...

The behavior of empty is unreliable. isset is not ambiguous.

Empty is identical to the not operator (!) except it also works on undefined variables, properties, and keys.

I could see it being depreciated for use on non-arrays, but at the moment the only other method of detecting an empty array is `!count($arr)`, which is significantly slower if the array isn't empty.

Ultimately this isn't a language issue, it's a training issue. If you're using empty in place of isset, you're doing it wrong, the both serve completely different purposes.

What you mean "unreliable"? It is completely reliable and described in the documentation. It doesn't fit some use cases, in these cases you could use other facilities provided by the language, PHP can not have separate language construct for every use case.

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.

That's exactly what I was going to say.

The author says this about parameter skipping:

   Personally I’m not particular fond of this proposal. 
   In my eyes code that needs this feature is just badly
   designed. Functions shouldn’t have 12 optional parameters.

I'm not fond of this proposal either, for it doesn't solve a problem named parameters do, which is that sometimes function parameters don't have a logical order, and cramming them into an array feel sloppy as hell.

The problem with that is it's already valid syntax with a different meaning.

    function foo($a, $b = "10", $c = "20") {}
    foo(1, $c=20);
    var_dump($c); // int(20)

The syntax would have to be unambiguous. Perhaps:

    foo(5, c: 30)

    foo(5, $c: 30);

    foo(5, $c => 30)

or something like that...

What people end up doing in practice is passing in arrays with key/value pairs. The => syntax would be the closest thing to the current way of doing things, except you'd get default values and type hinting. I'm all for it!

I'm still looking for a good way to combine array parameters with defaults and hinting in PHP 5.3. I've had some success using DTO's for primary API's:

  function foo(SomeDTO $data) { ... }
  foo(new SomeDTO(array("a" => "foo", "b" => 10)));
  
  class SomeDTO extends BaseDTO {
     /** @var string 
         @maxlength 10 */
     public var $a;
     /** @var int */
     public var $b = 20;
  }

The BaseDTO class uses reflection to parse the doc comments and figure out how to validate and set its input. It's the same idea as validation annotations in java. It works, but it's quite a heavy syntax, and I wish I had a lighter-weight alternative. I like PHP's loose typing inside an API's class, but when interfacing between API's I want strict typing.

Maybe I am missing something but never seen that in practice (the 'foo(1, $c=20)' bit), that's a really odd way to initialize a variable. Wouldn't mind if they change it, so that it breaks (with a warning or error). Or have you seen this syntax a lot?

> Very important as we incorporate more functional paradigms into the code.

There's nothing functional to skipping parameters, as far as I know. None of the functional languages I've used supports such a concept, nor would it make sense in most of them.

Reply on news.ycombinator.com