9 ms·

What PHP 5.5 might look like

154 points by nikic 14y ago

debacle 14y ago
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.
- leftnode 14y ago
  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.
  - debacle 14y ago
    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.
  - gilini 14y ago
    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.
  - ircmaxell 14y ago
    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...
    - Joeri 14y ago
      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.
    - soulclap 14y ago
      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?
- Spoom 14y ago
  I'm curious: Why do you think empty() should be deprecated? Do you think the same of isset?
  - debacle 14y ago
    http://www.zachstronaut.com/posts/2009/02/09/careful-with-php-empty.html http://www.zachstronaut.com/posts/2009/02/09/careful-with-ph... http://stackoverflow.com/questions/410002/fixing-the-php-empty-function http://stackoverflow.com/questions/410002/fixing-the-php-emp... The behavior of empty is unreliable. isset is not ambiguous.
    - wvenable 14y ago
      Empty is identical to the not operator (!) except it also works on undefined variables, properties, and keys.
    - ChiperSoft 14y ago
      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.
    - smsm42 14y ago
      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.
- masklinn 14y ago
  > 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.
Nervetattoo 14y ago
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.
- davedx 14y ago
  What's the deal with empty()? I've never used it myself but found people at the new place I work do use it.
  - leftnode 14y ago
    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.
  - deleted 14y ago
    [deleted]
Smerity 14y ago
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/ http://docs.python-requests.org/
- conradfr 14y ago
  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.
  - shakesbeard 14y ago
    The article clearly states that there are more features like a read-only keyword. https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
ardillamorris 14y ago
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.
- polyfractal 14y ago
  This is also the year of the Linux Desktop.
- madoublet 14y ago
  The beauty of PHP is that it is simple to learn and easy to setup. That is why it is popular and will continue to be. Additions, such as the easy-to-use password encryption, are brilliant because it will make it even easier to move from adding some dynamic functionality to building a full app.
- giulianob 14y ago
  There are many that come to mind CodeIgniter, CakePHP, Kohana, etc... are pretty damn good.
- billpatrianakos 14y ago
  Thanks for coming in and expressing your dislike of PHP. You offer something we surely haven't heard a thousand million times before from other random trolls. Which languages make you cool by mentioning them in passing? Python ans Ruby? Awesome. Didn't know that. Thank you so much for your insightful critique of PHP. "It's old so that makes it bad. Also, some real vague reference to the quality of the language and the current trendy frameworks". That's what I heard when I read that. There is nothing new to say about PHP in this area. Every criticism has been played out and overused here a thousand times over. Thanks for the well formed, specific and detailed opinion that's completely irrelevant in the context of the article.
- mootothemax 14y ago
  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. I'm not sure if you're serious, but there are plenty of frameworks on a par with Rails at least (nb: I have zero experience with Django). At the enterprise level, there's Symfony or Zend: http://symfony.com/ http://symfony.com/ http://www.zend.com/ http://www.zend.com/ If Rails is your thing, CakePHP shares some concepts (although I'll be the first to admit CakePHP has many flaws): http://cakephp.org/ http://cakephp.org/ Want something lightweight that's easy to jump into? CodeIgniter's the one for you! http://codeigniter.com/ http://codeigniter.com/ And finally, my favourite, Kohana. Absolutely infuriating since they essentially stopped writing documentation for new versions, but if I need to get something written quickly and reliably, this is my go-to call: http://kohanaframework.org/ http://kohanaframework.org/ There are tonnes of "serious" frameworks for PHP (I've certainly missed out a few), and frankly, if you're going to try to attack PHP, this is the wrong angle from which to do so.
musashibaka 14y ago
17 years old and a PHP Internals tinkerer... Awesome work Nikita, keep it up!
- Killswitch 14y ago
  Yes, indeed. I was blown away when I read his about page. So many people yap about their years of knowledge and that PHP has all these problems and can be fixed this way and that way, but when told to shut up and fork the language and do it. They say "I can't, because I don't know C', yet this 17 year old is doing just that. Kudos.
- ircmaxell 14y ago
  As someone who has worked with him for quite some time, all I can say is so very much agree. He blows me away left and right with his knowledge, ability and maturity (especially when it comes to code decisions). He's more senior than most developers that I know... So very much agree, keep it up!
- TazeTSchnitzel 14y ago
  As a 16-year-old, I wonder if I should stop thinking about developing my own language (which essentially would be F#), and fork PHP myself.
giulianob 14y ago
The "parameter skipping" functionality is really useful but IMO they should take the same route that C# did with named parameters. function create_query($where, $order_by, $join_type='', $execute = false, $report_errors = true) { ... } create_query("deleted=0", "name", report_errors: true); can even specify all parameters by name in different order create_query(order_by: "name", report_errors: true, where: "deleted=0");
mmuro 14y ago
Yet another array function. But, array_column does seem super useful.
lysol 14y ago
This is just a "would be nice" sort of post right? The main feature I'd want (list comprehensions) seems to be just a single programmer's guess at an upcoming feature with no real evidence.
- batista 14y ago
  RTFA
- courtewing 14y ago
  Pay close attention to the "status" listed under each header. Some of these features have already landed in master, and others are still in various states of proposal. The author links to the official RFC for most of the proposed features. I'm not sure if the list comprehensions feature has made it past the mailing list though.
zapt02 14y ago
The getters and setters change is looking great! Overall lots of good ideas!
masklinn 14y ago
I think a standard password hash API is a good thing (there was a proposal for such a thing for Python recently on -ideas, though it was essentially rejected in favor of recommending/using passlib), but I'm wary of having default cost factors, that seems unwise: what are the defaults, how are they decided to be ok, and more importantly in what context are they updated over time (and based on what data)?
- DomBlack 14y ago
  The problem with it in it's current form is it does not allow for an application pepper. Also I'd prefer it to support scrypt as well as bcrypt.
  - masklinn 14y ago
    > The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt and cost already are in the proposed API.
    - DomBlack 14y ago
      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, but your application code is safe the pepper increases the complexity of brute forcing, as they need to work out what the pepper is
      - warbiscuit 14y ago
        The most common pepper algorithm I've seen is doing e.g. "bcrypt(hmac_sha512(password, pepper), salt)" instead of "bcrypt(password, salt)". This has a number of advantages over working the pepper into the hash itself: 1) this wrapper can be applied to any hash scheme, regardless of it's internal structure or options. 2) it doesn't expose the pepper within the hash string. 3) brute-forcing the hash w/o the pepper means you're searching for the 64-byte binary string returned by hmac_sha512. whereas (assuming all inputs are ASCII) "md5(salt+pepper+password)" can still be brute-forced, just treat the pepper as part of the password you're looking for.
ShaneCurran 14y ago
Laravel already does alot of this stuff ^^^
bergie 14y ago
These sound like useful improvements, especially the new getter/setter syntax and scalar type hinting. However, what I'd really like to see in next PHP would be the Composer dependency manager bundled in, a bit like Node.js nowadays ships with NPM. This has really brought a new world of cross-project code sharing into PHP: http://packagist.org/ http://packagist.org/ I wrote a blog post on why this is important for improving the state of PHP: http://bergie.iki.fi/blog/composer_solves_the_php_code-sharing_problem/ http://bergie.iki.fi/blog/composer_solves_the_php_code-shari...
- ircmaxell 14y ago
  I think composer is a bit too young to introduce into the language. Perhaps it will prove out to be robust, but I'd wait a little while before introducing it to core...
  - wink 14y ago
    When you look at people complaining at the deprecation of 5.1 and 5.2, I'd rather not have any userland code shipped.
mikeash 14y ago
Regarding the "constant dereferencing" proposal, how do you even make a language parser that can't apply array operations to literals in the first place? I'm trying very hard not to bash on PHP here, and this is a completely honest question. I can't figure out how you'd even go about breaking that if you wanted to. Anyone know the background there?
- pbiggar 14y ago
  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 allow it, so this is probably the same.
  - mikeash 14y ago
    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.
    - pbiggar 14y ago
      Yeah, there's tons of special cases in the parser. I worked on phc (http://phpcompiler.org 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.
      - mikeash 14y ago
        Painful. Thanks for sharing your experience. Cool to ask such a question and get an answer from someone who's actually built something related.
deleted 14y ago
[deleted]
- josteink 14y ago
  If you are fine running a decade+ old OS, chances are you don't have a dire need to run a bleeding edge version of PHP locally.
  - mkopinsky 14y ago
    I don't know what you're responding to, but viewing your comment in isolation, I disagree. I work for a large hospital that has standardized on XP as the OS for desktop machines, and most of our server VMs are running Windows Server 2003. (Can't comment on what OS is hosting the VMs.) I don't have the freedom to upgrade my PC or the servers I deploy my code on, but that doesn't mean I should be stuck with an old version of PHP. No, I don't have a dire need. But almost no one has a dire need.
geon 14y ago
I was confused by the password hashing example since it doesn't appear to use a salt (which was the main reason to implement it at all). Even more confusing, the RCF says it will auto generate a salt if none is passed. The explanation, a bit further down in the eRFC is that the function password_hash doesn't actually return a password hash, but a string including the algorithm and options used, the salt and the hash itself. From the RFC: > It's important to note that the output of crypt() (and hence password_hash()) contains all the information that will be needed to verify the hash later. Therefore, if the default hashing algorithm changes, or the user changes their algorithm, old hashed passwords would still continue to function and will be validated properly.
pbiggar 14y ago
I was involved with PHP internals when type hinting came up for 5.3, and helped steer that discussion in some way [1]. It was a truly awful experience - at the time, the internals community was a very negative and poisonousness place. Does anyone still involved know if that has been fixed? [1] oh look, I'm still mentioned in the RFC :) - https://wiki.php.net/rfc/scalar_type_hinting_with_cast https://wiki.php.net/rfc/scalar_type_hinting_with_cast
- swivelmaster 14y ago
  Given that you're involved in this - why add "with cast"? I thought the whole point of the feature, in regards to classes and arrays, is to be absolutely strict about function arguments. Once you start down the path of "well, as long as it's sort of like that," then you might as well accept objects that have toString defined in place of strings. Having worked in a large PHP project for years and trying to get it to a point of letting new developers spin up pretty quickly (and use PHPStorm efficiently), STRICT type hinting is one of the best tools possible!
  - pbiggar 14y ago
    So I'm not involved in the current discussion, but I remember some stuff from the last discussion and in general. To start, you can consider the problem of type checking of scalars in a language with implicit type coercions. You're supposed to be able to treat 0 and 0.0 the same. At the same time, if you have a type check that says "int", you kinda expect to get an int. So "with cast" does that. I know a lot of people find that ugly, and that you want to strictly that you must receive an int, but that's just not how people use PHP, and it doesn't make sense in the context of the language. As an example, you want to be able to add type checks to all the functions in the standard library, many of whom treat null, "0", 0 and 0.0 to be the same. For PHP specifically, there is the additional consideration that PHP is supposed to be a newbie friendly language. There was a perception in the PHP internals community that newbie developers could not wrap their head around the concept of "types". I've heard people say that a developer shouldn't be required to think about what types his variable might hold. Clearly this is lunacy for many reasons, but there it is.
snorkel 14y ago
Conspicuously absent from PHP: array_copy() ... in order to copy-by-value on arrays containing references. Currently to do that you have to do a very fragile hack like this: $copy = array_flip(array_flip($original)); ... which is vulnerable to key-value collisions ... or you have to write your own homebrew array copy-by-value function.
- TazeTSchnitzel 14y ago
  File a bug report :)
  - smsm42 14y ago
    Better yet, file an RFC and a pull request.
    - TazeTSchnitzel 14y ago
      Yep. That's what I'm trying to do for something else :D
- nieksand 14y ago
  Still ugly, but at least it won't crap out if your data has duplicate values: $copy = array_map( function($v) { return $v; }, $original );
- ircmaxell 14y ago
  Very simple. Either: $copy = $original; Or, if you must have a function, function array_copy(array $a) { return $a; } Arrays use the normal copy-on-write semantics of PHP. They are not passed by reference or object handle... The only potential issue is if the array contains references deeper in.
gurkendoktor 14y ago
> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them. Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software? Or does this just mean that noone will actively test the binaries on XP anymore?
- z92 14y ago
  I can foresee them making a turn on this decision and continuing to support XP until developers actually stop using XP anymore. XP isn't going away anytime soon. It was nice to see short tags "<?" coming back in 5.4. Before that, they used to say, don't use short tags, it's dangerous, breaks things. But users resisted it, and every ISP kept it open. And now from PHP 5.4 short tag is ON, regardless of whether one setts it On or Off in php.ini.
  - stephenr 14y ago
    No actually, as of 5.4 <?= is always available. <?= and <? are not the same thing.
- cpeterso 14y ago
  I believe Visual Studio 2010 and 2012 generate code that imports MSVCRT functions that are not available on Windows 2000 or XP: https://connect.microsoft.com/VisualStudio/feedback/details/473978/vs2010s-c-runtime-library-introduces-dependencies-which-prevent-execution-on-windows-2k https://connect.microsoft.com/VisualStudio/feedback/details/... https://connect.microsoft.com/VisualStudio/feedback/details/526821/executables-built-with-visual-c-2010-do-not-run-on-windows-xp-prior-to-sp2 https://connect.microsoft.com/VisualStudio/feedback/details/...
  - gurkendoktor 14y ago
    The VS2010 MSVCRT still runs on Windows XP SP2+ as mentioned in your second link. The VS2012 MSVCRT will not run on XP initially, but a post-RTM patch to bring XP support back was mentioned on the VS blog[1]. So that would only prevent XP support between the VS2012 release and the post-RTM patch, and only if the PHP team upgraded at the first chance. [1]: http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-look-ahead-at-the-visual-studio-11-product-lineup-and-platform-support.aspx http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-lo...
Sander_Marechal 14y ago
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.
- philjohn 14y ago
  or at least throw a NPE which you can catch and handle.
- smsm42 14y ago
  Don't return null from that function. Return NullObject which has __call() { return $this; } - then you could chain as many such calls as you want and they'd be OK with nulls. Then you could check for NullObject as easily as you could check for null - if($result instanceof NullObject) etc.
psaintla 14y ago
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.
velodrome 14y ago
Is PHP JIT at least on the roadmap?
- RobAley 14y ago
  As far as I am aware, it is under consideration for Zend Engine 3 / PHP6. But certainly not for 5.5, and probably not in the 5.x series at all. Though how many 5.x releases are left is anyone’s guess, personally my crystal ball tells me we will get 5.6 followed by 6. My crystal ball also says we will all have flying cars by now.
- smsm42 14y ago
  Watch these guys: http://talariatech.com/ http://talariatech.com/

154 points by nikic 14y ago

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.

leftnode 14y ago
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.
- debacle 14y ago
  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.
- gilini 14y ago
  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.
- ircmaxell 14y ago
  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...
  - Joeri 14y ago
    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.
  - soulclap 14y ago
    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?
Spoom 14y ago
I'm curious: Why do you think empty() should be deprecated? Do you think the same of isset?
- debacle 14y ago
  http://www.zachstronaut.com/posts/2009/02/09/careful-with-php-empty.html http://www.zachstronaut.com/posts/2009/02/09/careful-with-ph... http://stackoverflow.com/questions/410002/fixing-the-php-empty-function http://stackoverflow.com/questions/410002/fixing-the-php-emp... The behavior of empty is unreliable. isset is not ambiguous.
  - wvenable 14y ago
    Empty is identical to the not operator (!) except it also works on undefined variables, properties, and keys.
  - ChiperSoft 14y ago
    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.
  - smsm42 14y ago
    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.
masklinn 14y ago
> 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.

Nervetattoo 14y ago

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.

davedx 14y ago
What's the deal with empty()? I've never used it myself but found people at the new place I work do use it.
- leftnode 14y ago
  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.
- deleted 14y ago
  [deleted]

Smerity 14y ago

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/ http://docs.python-requests.org/

conradfr 14y ago
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.
- shakesbeard 14y ago
  The article clearly states that there are more features like a read-only keyword. https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

ardillamorris 14y ago

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.

polyfractal 14y ago
This is also the year of the Linux Desktop.
madoublet 14y ago
The beauty of PHP is that it is simple to learn and easy to setup. That is why it is popular and will continue to be. Additions, such as the easy-to-use password encryption, are brilliant because it will make it even easier to move from adding some dynamic functionality to building a full app.
giulianob 14y ago
There are many that come to mind CodeIgniter, CakePHP, Kohana, etc... are pretty damn good.
billpatrianakos 14y ago
Thanks for coming in and expressing your dislike of PHP. You offer something we surely haven't heard a thousand million times before from other random trolls. Which languages make you cool by mentioning them in passing? Python ans Ruby? Awesome. Didn't know that. Thank you so much for your insightful critique of PHP. "It's old so that makes it bad. Also, some real vague reference to the quality of the language and the current trendy frameworks". That's what I heard when I read that. There is nothing new to say about PHP in this area. Every criticism has been played out and overused here a thousand times over. Thanks for the well formed, specific and detailed opinion that's completely irrelevant in the context of the article.
mootothemax 14y ago
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. I'm not sure if you're serious, but there are plenty of frameworks on a par with Rails at least (nb: I have zero experience with Django). At the enterprise level, there's Symfony or Zend: http://symfony.com/ http://symfony.com/ http://www.zend.com/ http://www.zend.com/ If Rails is your thing, CakePHP shares some concepts (although I'll be the first to admit CakePHP has many flaws): http://cakephp.org/ http://cakephp.org/ Want something lightweight that's easy to jump into? CodeIgniter's the one for you! http://codeigniter.com/ http://codeigniter.com/ And finally, my favourite, Kohana. Absolutely infuriating since they essentially stopped writing documentation for new versions, but if I need to get something written quickly and reliably, this is my go-to call: http://kohanaframework.org/ http://kohanaframework.org/ There are tonnes of "serious" frameworks for PHP (I've certainly missed out a few), and frankly, if you're going to try to attack PHP, this is the wrong angle from which to do so.

musashibaka 14y ago

17 years old and a PHP Internals tinkerer... Awesome work Nikita, keep it up!

Killswitch 14y ago
Yes, indeed. I was blown away when I read his about page. So many people yap about their years of knowledge and that PHP has all these problems and can be fixed this way and that way, but when told to shut up and fork the language and do it. They say "I can't, because I don't know C', yet this 17 year old is doing just that. Kudos.
ircmaxell 14y ago
As someone who has worked with him for quite some time, all I can say is so very much agree. He blows me away left and right with his knowledge, ability and maturity (especially when it comes to code decisions). He's more senior than most developers that I know... So very much agree, keep it up!
TazeTSchnitzel 14y ago
As a 16-year-old, I wonder if I should stop thinking about developing my own language (which essentially would be F#), and fork PHP myself.

giulianob 14y ago

The "parameter skipping" functionality is really useful but IMO they should take the same route that C# did with named parameters. function create_query($where, $order_by, $join_type='', $execute = false, $report_errors = true) { ... } create_query("deleted=0", "name", report_errors: true); can even specify all parameters by name in different order create_query(order_by: "name", report_errors: true, where: "deleted=0");

mmuro 14y ago

Yet another array function. But, array_column does seem super useful.

lysol 14y ago

This is just a "would be nice" sort of post right? The main feature I'd want (list comprehensions) seems to be just a single programmer's guess at an upcoming feature with no real evidence.

batista 14y ago
RTFA
courtewing 14y ago
Pay close attention to the "status" listed under each header. Some of these features have already landed in master, and others are still in various states of proposal. The author links to the official RFC for most of the proposed features. I'm not sure if the list comprehensions feature has made it past the mailing list though.

zapt02 14y ago

The getters and setters change is looking great! Overall lots of good ideas!

masklinn 14y ago

I think a standard password hash API is a good thing (there was a proposal for such a thing for Python recently on -ideas, though it was essentially rejected in favor of recommending/using passlib), but I'm wary of having default cost factors, that seems unwise: what are the defaults, how are they decided to be ok, and more importantly in what context are they updated over time (and based on what data)?

DomBlack 14y ago
The problem with it in it's current form is it does not allow for an application pepper. Also I'd prefer it to support scrypt as well as bcrypt.
- masklinn 14y ago
  > The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt and cost already are in the proposed API.
  - DomBlack 14y ago
    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, but your application code is safe the pepper increases the complexity of brute forcing, as they need to work out what the pepper is
    - warbiscuit 14y ago
      The most common pepper algorithm I've seen is doing e.g. "bcrypt(hmac_sha512(password, pepper), salt)" instead of "bcrypt(password, salt)". This has a number of advantages over working the pepper into the hash itself: 1) this wrapper can be applied to any hash scheme, regardless of it's internal structure or options. 2) it doesn't expose the pepper within the hash string. 3) brute-forcing the hash w/o the pepper means you're searching for the 64-byte binary string returned by hmac_sha512. whereas (assuming all inputs are ASCII) "md5(salt+pepper+password)" can still be brute-forced, just treat the pepper as part of the password you're looking for.

ShaneCurran 14y ago

Laravel already does alot of this stuff ^^^

bergie 14y ago

These sound like useful improvements, especially the new getter/setter syntax and scalar type hinting. However, what I'd really like to see in next PHP would be the Composer dependency manager bundled in, a bit like Node.js nowadays ships with NPM. This has really brought a new world of cross-project code sharing into PHP: http://packagist.org/ http://packagist.org/ I wrote a blog post on why this is important for improving the state of PHP: http://bergie.iki.fi/blog/composer_solves_the_php_code-sharing_problem/ http://bergie.iki.fi/blog/composer_solves_the_php_code-shari...

ircmaxell 14y ago
I think composer is a bit too young to introduce into the language. Perhaps it will prove out to be robust, but I'd wait a little while before introducing it to core...
- wink 14y ago
  When you look at people complaining at the deprecation of 5.1 and 5.2, I'd rather not have any userland code shipped.

mikeash 14y ago

Regarding the "constant dereferencing" proposal, how do you even make a language parser that can't apply array operations to literals in the first place? I'm trying very hard not to bash on PHP here, and this is a completely honest question. I can't figure out how you'd even go about breaking that if you wanted to. Anyone know the background there?

pbiggar 14y ago
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 allow it, so this is probably the same.
- mikeash 14y ago
  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.
  - pbiggar 14y ago
    Yeah, there's tons of special cases in the parser. I worked on phc (http://phpcompiler.org 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.
    - mikeash 14y ago
      Painful. Thanks for sharing your experience. Cool to ask such a question and get an answer from someone who's actually built something related.

deleted 14y ago

[deleted]

josteink 14y ago
If you are fine running a decade+ old OS, chances are you don't have a dire need to run a bleeding edge version of PHP locally.
- mkopinsky 14y ago
  I don't know what you're responding to, but viewing your comment in isolation, I disagree. I work for a large hospital that has standardized on XP as the OS for desktop machines, and most of our server VMs are running Windows Server 2003. (Can't comment on what OS is hosting the VMs.) I don't have the freedom to upgrade my PC or the servers I deploy my code on, but that doesn't mean I should be stuck with an old version of PHP. No, I don't have a dire need. But almost no one has a dire need.

geon 14y ago

I was confused by the password hashing example since it doesn't appear to use a salt (which was the main reason to implement it at all). Even more confusing, the RCF says it will auto generate a salt if none is passed. The explanation, a bit further down in the eRFC is that the function password_hash doesn't actually return a password hash, but a string including the algorithm and options used, the salt and the hash itself. From the RFC: > It's important to note that the output of crypt() (and hence password_hash()) contains all the information that will be needed to verify the hash later. Therefore, if the default hashing algorithm changes, or the user changes their algorithm, old hashed passwords would still continue to function and will be validated properly.

pbiggar 14y ago

I was involved with PHP internals when type hinting came up for 5.3, and helped steer that discussion in some way [1]. It was a truly awful experience - at the time, the internals community was a very negative and poisonousness place. Does anyone still involved know if that has been fixed? [1] oh look, I'm still mentioned in the RFC :) - https://wiki.php.net/rfc/scalar_type_hinting_with_cast https://wiki.php.net/rfc/scalar_type_hinting_with_cast

swivelmaster 14y ago
Given that you're involved in this - why add "with cast"? I thought the whole point of the feature, in regards to classes and arrays, is to be absolutely strict about function arguments. Once you start down the path of "well, as long as it's sort of like that," then you might as well accept objects that have toString defined in place of strings. Having worked in a large PHP project for years and trying to get it to a point of letting new developers spin up pretty quickly (and use PHPStorm efficiently), STRICT type hinting is one of the best tools possible!
- pbiggar 14y ago
  So I'm not involved in the current discussion, but I remember some stuff from the last discussion and in general. To start, you can consider the problem of type checking of scalars in a language with implicit type coercions. You're supposed to be able to treat 0 and 0.0 the same. At the same time, if you have a type check that says "int", you kinda expect to get an int. So "with cast" does that. I know a lot of people find that ugly, and that you want to strictly that you must receive an int, but that's just not how people use PHP, and it doesn't make sense in the context of the language. As an example, you want to be able to add type checks to all the functions in the standard library, many of whom treat null, "0", 0 and 0.0 to be the same. For PHP specifically, there is the additional consideration that PHP is supposed to be a newbie friendly language. There was a perception in the PHP internals community that newbie developers could not wrap their head around the concept of "types". I've heard people say that a developer shouldn't be required to think about what types his variable might hold. Clearly this is lunacy for many reasons, but there it is.

snorkel 14y ago

Conspicuously absent from PHP: array_copy() ... in order to copy-by-value on arrays containing references. Currently to do that you have to do a very fragile hack like this: $copy = array_flip(array_flip($original)); ... which is vulnerable to key-value collisions ... or you have to write your own homebrew array copy-by-value function.

TazeTSchnitzel 14y ago
File a bug report :)
- smsm42 14y ago
  Better yet, file an RFC and a pull request.
  - TazeTSchnitzel 14y ago
    Yep. That's what I'm trying to do for something else :D
nieksand 14y ago
Still ugly, but at least it won't crap out if your data has duplicate values: $copy = array_map( function($v) { return $v; }, $original );
ircmaxell 14y ago
Very simple. Either: $copy = $original; Or, if you must have a function, function array_copy(array $a) { return $a; } Arrays use the normal copy-on-write semantics of PHP. They are not passed by reference or object handle... The only potential issue is if the array contains references deeper in.

gurkendoktor 14y ago

> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them. Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software? Or does this just mean that noone will actively test the binaries on XP anymore?

z92 14y ago
I can foresee them making a turn on this decision and continuing to support XP until developers actually stop using XP anymore. XP isn't going away anytime soon. It was nice to see short tags "<?" coming back in 5.4. Before that, they used to say, don't use short tags, it's dangerous, breaks things. But users resisted it, and every ISP kept it open. And now from PHP 5.4 short tag is ON, regardless of whether one setts it On or Off in php.ini.
- stephenr 14y ago
  No actually, as of 5.4 <?= is always available. <?= and <? are not the same thing.
cpeterso 14y ago
I believe Visual Studio 2010 and 2012 generate code that imports MSVCRT functions that are not available on Windows 2000 or XP: https://connect.microsoft.com/VisualStudio/feedback/details/473978/vs2010s-c-runtime-library-introduces-dependencies-which-prevent-execution-on-windows-2k https://connect.microsoft.com/VisualStudio/feedback/details/... https://connect.microsoft.com/VisualStudio/feedback/details/526821/executables-built-with-visual-c-2010-do-not-run-on-windows-xp-prior-to-sp2 https://connect.microsoft.com/VisualStudio/feedback/details/...
- gurkendoktor 14y ago
  The VS2010 MSVCRT still runs on Windows XP SP2+ as mentioned in your second link. The VS2012 MSVCRT will not run on XP initially, but a post-RTM patch to bring XP support back was mentioned on the VS blog[1]. So that would only prevent XP support between the VS2012 release and the post-RTM patch, and only if the PHP team upgraded at the first chance. [1]: http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-look-ahead-at-the-visual-studio-11-product-lineup-and-platform-support.aspx http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-lo...

Sander_Marechal 14y ago

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.

philjohn 14y ago
or at least throw a NPE which you can catch and handle.
smsm42 14y ago
Don't return null from that function. Return NullObject which has __call() { return $this; } - then you could chain as many such calls as you want and they'd be OK with nulls. Then you could check for NullObject as easily as you could check for null - if($result instanceof NullObject) etc.

psaintla 14y ago

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.

velodrome 14y ago

Is PHP JIT at least on the roadmap?

RobAley 14y ago
As far as I am aware, it is under consideration for Zend Engine 3 / PHP6. But certainly not for 5.5, and probably not in the 5.x series at all. Though how many 5.x releases are left is anyone’s guess, personally my crystal ball tells me we will get 5.6 followed by 6. My crystal ball also says we will all have flying cars by now.
smsm42 14y ago
Watch these guys: http://talariatech.com/ http://talariatech.com/