Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What PHP 5.5 might look like

nikic.github.com

Post reply on HN
Print view View original

91–100 of 139 posts

Re: What PHP 5.5 might look like

#91

Post by pbiggar »

mikeash wrote: post #88
pbiggar wrote: post #69

Earlier quoted context omitted.

This would probably ban "4[5]" but not "$x = 4; $x[5]". PHP enforces a lot of things in the parser (as opposed to making bytecode and having a simple type checker). Instead of having a general "expression" type which can be dereferenced, they have different rules for scalars, strings, variables, function calls, etc. For a long time, you couldn't dereference the result of a function call, because the parser didn't all…

Enforcing it in the parser seems so horribly wrong. If you want to disallow stuff like 4[5] at compile time then you should do that in a separate pass on the AST, not in the parser itself. That's ought to be a semantic error, not a syntax error. Treating that separately would require all manner of special cases. But, I guess that must be what they do.

Yeah, there's tons of special cases in the parser. I worked on phc (http://phpcompiler.org), so I've read the PHP parser and helped write some of our own. We took the AST approach and it worked out pretty well. But PHP was written before its authors knew good interpreter design, and its currently very hard to refactor it out to a better design.

Re: What PHP 5.5 might look like

#92

Post by Sander_Marechal »

The proposals look great! But I'm missing one thing: Less fatal errors, or a better way to catch them. Especially for the case of calling a method on a null value. E.g.

    $foo->getBar()->getBaz()
If getBar() return NULL for some reason, you get a fatal error which you cannot catch and handle without reverting to uglu hacks with a shutdown function.

My personal preference would be to have that statement return NULL and raise a warning or notice, alike to using uninitialized variables.

Re: What PHP 5.5 might look like

#93

Post by psaintla »

If there is scalar type hinting I wonder if that will lead to real method overloading by adding methods with different signatures or if devs will have to stick with the __call magic method, which I despise.

Re: What PHP 5.5 might look like

#94

Post by masklinn »

bnr wrote: post #90
DomBlack wrote: post #78

Earlier quoted context omitted.

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

If the attacker has one known password in the database, finding the pepper has the same difficulty as finding one password in a DB without pepper.

That is not entirely true: the pepper is usually randomly generated, so a "smart" brute-forcing tool (using combinations and substitutions on a base corpus) will have a much harder time matching something.

Re: What PHP 5.5 might look like

#95

Post by philjohn »

Sander_Marechal wrote: post #92

The proposals look great! But I'm missing one thing: Less fatal errors, or a better way to catch them. Especially for the case of calling a method on a null value. E.g. $foo->getBar()->getBaz() If getBar() return NULL for some reason, you get a fatal error which you cannot catch and handle without reverting to uglu hacks with a shutdown function. My personal preference would be to have that statement return NULL and…

or at least throw a NPE which you can catch and handle.

Re: What PHP 5.5 might look like

#96

Post by Joeri »

ircmaxell wrote: post #48
leftnode wrote: post #4

Earlier quoted context omitted.

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.

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) or foo(5, $c: 30); or 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.

Re: What PHP 5.5 might look like

#97

Post by geon »

Tloewald wrote: post #85
geon wrote: post #60

Earlier quoted context omitted.

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

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

Re: What PHP 5.5 might look like

#98

Post by mikeash »

pbiggar wrote: post #91
mikeash wrote: post #88

Earlier quoted context omitted.

Enforcing it in the parser seems so horribly wrong. If you want to disallow stuff like 4[5] at compile time then you should do that in a separate pass on the AST, not in the parser itself. That's ought to be a semantic error, not a syntax error. Treating that separately would require all manner of special cases. But, I guess that must be what they do.

Yeah, there's tons of special cases in the parser. I worked on phc ( http://phpcompiler.org ), so I've read the PHP parser and helped write some of our own. We took the AST approach and it worked out pretty well. But PHP was written before its authors knew good interpreter design, and its currently very hard to refactor it out to a better design.

Painful. Thanks for sharing your experience. Cool to ask such a question and get an answer from someone who's actually built something related.

Re: What PHP 5.5 might look like

#100

Post by TazeTSchnitzel »

Smerity wrote: post #77
geon wrote: post #60

Earlier quoted context omitted.

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

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

Post reply on HN