8 ms·

List of possible changes, updates, additions for PHP 6

65 points by mariuz 13y ago

allendoerfer 13y ago
I fear, they will give unicode another try, fail again and just keep on bloating the API. I bet there is a language out there, which way to set or get attributes, PHP has not yet copied.
thomasfoster96 13y ago
They had me at "Unicode support". Assuming it somehow works.
- hrktb 13y ago
  If the internal representatiom changes, I wonder how much the current mb_* functions will be affected. I hope reimplementing them is trivial and doesn't affect edge cases. I've seen a lot of very very hacky code relying on them, there was no evident clever solution, and it would be a nightmare to go back on all these and test all the wicked pattern they were supposed to cover.
nikic 13y ago
To make sure you have proper context: With one or two exceptions, those proposals are just vague ideas of what we might want to do in PHP 6. It says very little about what will actually go in. Most of it won't, at least I dearly hope so - otherwise we wouldn't get a release in the next decade ;)
jmnicolas 13y ago
Considering all its problems, I wonder why PHP has not been forked already in a saner language. I mean who in 2014 is going to start a new project in PHP apart from people that can't be bothered to learn something else ?
- ssiddharth 13y ago
  PHP 5.3+ isn't really as bad as people make it out to be. Sure, it's not flashy, but it can definitely get the job done. I've been exploring Laravel lately and it's certainly a lot of fun.
- tiquorsj 13y ago
  Maybe people who already build and maintain apps in one of the most widely used language on the web?
- dnzm 13y ago
  > I mean who in 2014 is going to start a new project in PHP apart from people that can't be bothered to learn something else ? People who refrain from having the standard knee-jerk "lol php is bad" reaction whenever it's being mentioned. Of course the language has its warts and pitfalls, but then again, most languages do, and it's a fairly usable tool for a fair amount of jobs. Care to show me a language with the same adoption rate (especially among hosters, which is something a lot of web devs simply have to keep in mind), ease of getting a project from zero to gone live?
- ohwp 13y ago
  For me the pros/cons balance is still heavy on the pros side. So yeah I'm starting PHP projects in 2014. And as in every other language your own skills are the biggest bottleneck.
- lucian1900 13y ago
  It's easier to just use one of the many other better languages.
- jbrooksuk 13y ago
  Frameworks such as Laravel has made this much less of a problem.
  - Zelphyr 13y ago
    Frameworks replace one problem with seven others.
- tim333 13y ago
  For me the main reason to use PHP rather than say Python is that there is a load of not too bad open source stuff out there that you can use and modify.
  - tragic 13y ago
    Uh... http://pypi.python.org/ http://pypi.python.org/ - 40,037 packages http://rubygems.org/ http://rubygems.org/ - 70,678 packages http://www.cpan.org/ http://www.cpan.org/ - 129,447 packages http://packagist.org http://packagist.org - 24,244 packages There's a lot of open source code out there for all major languages. And, based on the canonical package indexes, a lot less for PHP than the other main contenders in the OSS web-ready scripting space (although, obviously, PHP is very domain-specific compared to the others I've listed, so the comparison is not completely fair - even with that caveat, however, I would expect Perl and Ruby to have PHP licked). There are compelling reasons to use PHP - omnipresence, ease of deployment - but this isn't one of them.
    - krapp 13y ago
      To be fair, Composer can handle a lot more than just the list on Packagist, so I don't how "canonical" Packagist really is for php, as opposed to being the "default", if it matters. https://getcomposer.org/doc/05-repositories.md#types https://getcomposer.org/doc/05-repositories.md#types Though I'd agree it is still a weak argument in favor of PHP.
    - tim333 13y ago
      Maybe but the couple of jobs I did / am thinking of doing were putting up a jobs board and a dating site. I found jobberbase for jobs and osdate for dating which are free and you could stick up there and modify a bit. Are there equivalents in Python say? Or Ruby?
  - pekk 13y ago
    The same thing is true of Python, though. Use PHP if you want, but not because Python doesn't have open source stuff out there
- jbeja 13y ago
  My cients's hosting providers only support PHP, so yeah...
- Xdes 13y ago
  Check out Hack for HHVM[0][1][2]. It's a lot saner than PHP, but it's not documented or well known outside Facebook. [0]: Strangle Loop 2013: Keith Adams, Facebook: Taking PHP Seriously https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf https://raw.github.com/strangeloop/StrangeLoop2013/master/sl... [1]: CUFP 2013: Julien Verlaguet, Facebook: Analyzing PHP statically https://www.youtube.com/watch?v=gKWNjFagR9k https://www.youtube.com/watch?v=gKWNjFagR9k [2]: HHVM and Hack – Can We Expect Them to Replace PHP? http://www.sitepoint.com/hhvm-hack-part-1/ http://www.sitepoint.com/hhvm-hack-part-1/
nolok 13y ago
> Support of UTF-8 for the language itself, as PHP currently allows non ascii encoding in scripts, I would recommend to stop supporting it, except in comments. Yes, how dare these people use their own alphabet.
- trebor 13y ago
  At least when your library is guaranteed to have ASCII functions and objects I can still type them. Otherwise non-ASCII libraries would be utterly useless to me.
  - nolok 13y ago
    But that's a different problem altogether, being able to do my own code in my own language and making things I share properly accessible and usable to everyone. Also, you should note the recommendation I quote is not about adding the ability to use non latin alphabet, this is about removing that ability. It's been there for over a decade and I don't see that rendering libraries developers brainless, so I would say your point doesn't apply.
SixSigma 13y ago
to join in the other Unicode posts Utf is not Unicode https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-is-not-utf/ https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-i...
ohwp 13y ago
Sometimes I wonder how important backward compatibility is. A lot of <=PHP4 libs wont run on a modern server so there are already compatibility issues. Maybe PHP6 could be a complete cleanup. And maybe the focus shouldn't be on backward compatibility but on running <6 and 6 side by side.
- dnzm 13y ago
  Agreed. Backward compatibility is nice, but you have to draw the line somewhere.
- frik 13y ago
  They better keep the backward compatibility, or you face the fiasco of Python 2 vs 3. The way that PHP deprecate API functions slowly over a period of time is prefered.
  - ohwp 13y ago
    Well I was thinking about Python when I wrote my comment :) One of the problems with Python is that they almost encouraged writing code in 2 and porting it to 3. Also: Python 3 is almost a complete different language. It would be the same when PHP6 would use a + as string concatenation. Such changes would turn it into a complete different language.
    - frik 13y ago
      Hopefully, PHP.net community won't go this route. The C-like syntax and the more or less stable code base (compatibility) are the main advantages over Python, Ruby, Go.
    - Pacabel 13y ago
      Have you ever actually used Python 2 and Python 3? Python 3 is not "almost a complete different language", as you put it. Somebody who has used both will notice that Python 3 is syntactically and semantically almost identical to Python 2 in most respects. The main differences are in terms of removing redundancy, removing outdated features and functionality, increasing consistency, vastly improved Unicode support, and standard library improvements. A developer with Python 2 experience should be able to pick up Python 3 in about 30 minutes, at the most. That's not what we'd expect were Python 3 "almost a complete different language".
jiggy2011 13y ago
The biggest hurdle I find in PHP at the moment is how difficult it is to get a debugger working. XDebug requires a bunch of installation and configuration and the PHP built in webserver doesn't seem to solve this problem at all. Most PHP programmers seem to have given up and resorted to using echo for debugging.
- dnzm 13y ago
  apt-get install php5-xdebug and enabling it in the config isn't exactly hard. Getting it to integrate with your IDE might be slightly more involved, but still no rocket science. It's also something you only have to do once, on your development box. So I don't really consider that a hurdle.
  - jiggy2011 13y ago
    At which point it will happily ignore all of your breakpoints unless you invoke the right voodoo to make everything line up and do this every time you want to use a new system or VM for debugging. Total contrast to every other language where you don't have to think about this stuff.
  - hrktb 13y ago
    This is true 90% of the time. From there, some libraries like ezpublish will cause all sort of problems with xdebug depending on where you put the breakpoint (it might be due to the number of recursive call or stack depth), and you'd really want to enable or disable debugging case by case, from your IDE ideally. Then debugging on a non dev server means installing a new package, configuring it and disable it afterwards just in case it has ill adverse effects. Then some eclipse pdt versions were stuck when using xdebug on some configs. Overall it works, but in practice, there's not enough cases IMO where step by step debugging is valuable enough to bother dealing with the not so exceptional weird things.
  - porker 13y ago
    > Getting it to integrate with your IDE might be slightly more involved, but still no rocket science. Which IDE do you use? Granted, most of my issues come from the IDE vendor's browser extension, which only triggers debugging when there's an 'R' in the month... which is highly frustrating.
frik 13y ago
I see no "optional static typing" in the list. Would be great if PHP.net and HHVM (Facebook's HipHopPHP) would go on in the same direction (somehow).
chriswarbo 13y ago
The main pain-point I have with PHP is how clunky its functions are; it seems like first-class functions have only been added so they can tick a box on their feature list, since many aspects of PHP make them unnecessarily hard to use. Passing function names around as strings is, of course, a hideous consequence of using separate namespaces for functions (foo) and variables ($foo), so it's at least understandable. Having to explicitly list a function's free variables with "use" is a hideous consequence of not having lexical scope from the start, so again it's understandable. What I don't understand is why functions aren't first-class in PHP's parser. For example, the parser doesn't know that functions may be returned from other functions: $foo = function() { return function() { echo "Hello;" }; }; $foo()(); // Parse error Instead we have to perform some indirection like this: call_user_func($foo()); Or like this: $bar = $foo(); $bar(); Likewise, the parser doesn't realise that functions may be stored in objects: $baz = new stdClass; $baz->quux = $foo(); $baz->quux(); // Error, no such method Again, we have to add an indirection: call_user_func($baz->quux); Or $foobar = $bar->quux; $foobar(); Named functions can't be closures, even though we can declare them anywhere, presumably for historical reasons, ie. this is a syntax error: function foo($bar) { function baz() use ($bar) { echo $bar; } } Another example of making it unnecessarily hard to use functions is iterable objects, which can only be iterated via foreach loops (ie. there is no way to map, reduce or filter them). Of course, I could also complain about no tail-call optimisation, functions not being curried, etc. but those aren't PHP-specific since very few scripting languages seem to get them right for some reason :(
- Udo 13y ago
  You're right that the parser would benefit from some more work to make edge cases like $foo()() work correctly. It'd be the single most important feature for a 6.x version as far as I'm concerned.
  - chriswarbo 13y ago
    It wouldn't need to be a version 6 feature, since it wouldn't break backwards-compatibility, but it may end up having to wait if that part of the interpreter is particularly gnarly (I've played with PHP's C code and I could see why it may be difficult!). Also, I'd hesitate to call "$foo()()" an 'edge case', since that implies that it's somehow different to any other function call. Making such a distinction is exactly what PHP got wrong here, ie. the parser should allow any expression to be called as a function, including other function calls and property lookups. Presumably there are two reasons why this happened: 1) Languages with first-class functions (and lexically-scoped closures) have fewer distinct features than languages without them; ie. functions are no longer distinct from other values (ints, bools, etc.), function names are no longer distinct from variable names (foo vs. $foo), methods are no longer distinct from properties ($foo->bar() could be a method call or a function call), functions and classes begin to overlap (lexical scope competes with instantiation and inheritance for resolving free variables) 2) For performance reasons, when these features were still distinct, they were branched on as early as possible, ie. in the parser. Essentially the problem is that the parser is still making distinctions which first-class functions have unified. The solution is to delay committing to these branches until further down the pipeline, ie. using a generic "expression" token, which "$foo" and "<expression>()" both parse to. The action to take can be resolved at runtime (when the value of the expression is known). In other words, there should be no difference between "<token>(<args>)" and "call_user_func(<token>, <args>)" (except maybe for things like pass-by-reference).
wcummings 13y ago
I can't wait for PHP6 to be released for the second time. I already own a book about it!
Thiz 13y ago
If only php changed concatenation from . to + and then used . for classes and packages I believe it would have a bigger impact. So honest question, what if somebody forked php and made those simple changes, how many people would switch? I would without hesitation.
- krapp 13y ago
  I wouldn't. I do find the use of . for concatenating strings to be annoying, but I wouldn't switch to a PHP fork that didn't also address bigger issues (saner function support, optional strong typing, named params maybe, operator overloading.) But then at some point you no longer have PHP you may have something which is close enough to an existing language that just switching to it becomes a more palatable option.
  - Thiz 13y ago
    As a hobbyist and freelancer I don't use any of these 'bigger issues' (saner function support, optional strong typing, named params maybe, operator overloading.) for my casual projects. So no, I'd benefit the most with a cleaner syntax than with cooking unicorns in fairy sauce. And I believe 80% of casual programmers agree with me. Pareto wins.
    - aaronem 13y ago
      Syntactic headaches mean less than semantic ones. PHP fails to support, or supports quite poorly, many semantics which more competently designed languages handle well. If PHP is your primary, or worse your only, programming language, then this deficit leaves you at a disadvantage when it comes to growing more skilled in your craft, because after a while you're not learning new things which generalize across languages, but rather learning how to work around the famously irreducible piles of manure unique to PHP. You can get quite good at doing that, of course, and it's even a useful professional skill, there being so much PHP code in the world, and most of it awful. But doing so does not make you a better programmer, because at best it teaches you nothing useful about how to use less programmer-hostile languages, and at worst it inculcates habits which will prove actively harmful in any later effort to develop skills in such languages. That you are unable to appreciate this qualitative distinction does nothing to erase its existence, but it does provide an excellent example of the conceptual deficiencies which result from a PHP-centric perspective on programming -- even something as trivial as proper first-class functions you dismiss as "cooking unicorns in fairy sauce", and since PHP doesn't have them, how would you know otherwise? Whether you choose to address these deficits in your education is, of course, entirely your lookout. I'm just here to point out that they exist. You're free to argue otherwise, should you so choose, but you'll be wrong to do so; I speak here from experience gained in working with people who similarly mistook PHP for a worthwhile general-purpose web development language, who began their programming careers by specializing in it, and who in so doing unwittingly stunted their professional growth in precisely the manner I describe. Some overcame it, and matured into truly professional programmers with whom it was a pleasure to work; some did not, and most of those, as far as I've been able to keep track, eventually drifted out of the field entirely. All, having been seduced by that syphilitic temptress of innocents we call PHP, suffered unduly as a result. (I'd have been among them myself if not for early exposure to Perl, which for all its warts is a thousand times preferable to PHP; having cut my teeth on a language which is merely bad, I was equipped in my first encounter with PHP to recognize the legendarily awful when I saw it.) It's for reasons like these that, to borrow a quote from the UNIX-HATERS Handbook, "I'm rather surprised that [Rasmus Lerdorf] is still walking around alive"; indeed, long may he continue to do so, for if there's a special hell for programmers, then in its frozen ninth circle there must surely be a waiting hole in the ice with his name carved around the edge -- or, just possibly, a throne.

65 points by mariuz 13y ago

I fear, they will give unicode another try, fail again and just keep on bloating the API. I bet there is a language out there, which way to set or get attributes, PHP has not yet copied.

thomasfoster96 13y ago

They had me at "Unicode support". Assuming it somehow works.

hrktb 13y ago
If the internal representatiom changes, I wonder how much the current mb_* functions will be affected. I hope reimplementing them is trivial and doesn't affect edge cases. I've seen a lot of very very hacky code relying on them, there was no evident clever solution, and it would be a nightmare to go back on all these and test all the wicked pattern they were supposed to cover.

nikic 13y ago

To make sure you have proper context: With one or two exceptions, those proposals are just vague ideas of what we might want to do in PHP 6. It says very little about what will actually go in. Most of it won't, at least I dearly hope so - otherwise we wouldn't get a release in the next decade ;)

jmnicolas 13y ago

Considering all its problems, I wonder why PHP has not been forked already in a saner language. I mean who in 2014 is going to start a new project in PHP apart from people that can't be bothered to learn something else ?

ssiddharth 13y ago
PHP 5.3+ isn't really as bad as people make it out to be. Sure, it's not flashy, but it can definitely get the job done. I've been exploring Laravel lately and it's certainly a lot of fun.
tiquorsj 13y ago
Maybe people who already build and maintain apps in one of the most widely used language on the web?
dnzm 13y ago
> I mean who in 2014 is going to start a new project in PHP apart from people that can't be bothered to learn something else ? People who refrain from having the standard knee-jerk "lol php is bad" reaction whenever it's being mentioned. Of course the language has its warts and pitfalls, but then again, most languages do, and it's a fairly usable tool for a fair amount of jobs. Care to show me a language with the same adoption rate (especially among hosters, which is something a lot of web devs simply have to keep in mind), ease of getting a project from zero to gone live?
ohwp 13y ago
For me the pros/cons balance is still heavy on the pros side. So yeah I'm starting PHP projects in 2014. And as in every other language your own skills are the biggest bottleneck.
lucian1900 13y ago
It's easier to just use one of the many other better languages.
jbrooksuk 13y ago
Frameworks such as Laravel has made this much less of a problem.
- Zelphyr 13y ago
  Frameworks replace one problem with seven others.
tim333 13y ago
For me the main reason to use PHP rather than say Python is that there is a load of not too bad open source stuff out there that you can use and modify.
- tragic 13y ago
  Uh... http://pypi.python.org/ http://pypi.python.org/ - 40,037 packages http://rubygems.org/ http://rubygems.org/ - 70,678 packages http://www.cpan.org/ http://www.cpan.org/ - 129,447 packages http://packagist.org http://packagist.org - 24,244 packages There's a lot of open source code out there for all major languages. And, based on the canonical package indexes, a lot less for PHP than the other main contenders in the OSS web-ready scripting space (although, obviously, PHP is very domain-specific compared to the others I've listed, so the comparison is not completely fair - even with that caveat, however, I would expect Perl and Ruby to have PHP licked). There are compelling reasons to use PHP - omnipresence, ease of deployment - but this isn't one of them.
  - krapp 13y ago
    To be fair, Composer can handle a lot more than just the list on Packagist, so I don't how "canonical" Packagist really is for php, as opposed to being the "default", if it matters. https://getcomposer.org/doc/05-repositories.md#types https://getcomposer.org/doc/05-repositories.md#types Though I'd agree it is still a weak argument in favor of PHP.
  - tim333 13y ago
    Maybe but the couple of jobs I did / am thinking of doing were putting up a jobs board and a dating site. I found jobberbase for jobs and osdate for dating which are free and you could stick up there and modify a bit. Are there equivalents in Python say? Or Ruby?
- pekk 13y ago
  The same thing is true of Python, though. Use PHP if you want, but not because Python doesn't have open source stuff out there
jbeja 13y ago
My cients's hosting providers only support PHP, so yeah...
Xdes 13y ago
Check out Hack for HHVM[0][1][2]. It's a lot saner than PHP, but it's not documented or well known outside Facebook. [0]: Strangle Loop 2013: Keith Adams, Facebook: Taking PHP Seriously https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf https://raw.github.com/strangeloop/StrangeLoop2013/master/sl... [1]: CUFP 2013: Julien Verlaguet, Facebook: Analyzing PHP statically https://www.youtube.com/watch?v=gKWNjFagR9k https://www.youtube.com/watch?v=gKWNjFagR9k [2]: HHVM and Hack – Can We Expect Them to Replace PHP? http://www.sitepoint.com/hhvm-hack-part-1/ http://www.sitepoint.com/hhvm-hack-part-1/

nolok 13y ago

> Support of UTF-8 for the language itself, as PHP currently allows non ascii encoding in scripts, I would recommend to stop supporting it, except in comments. Yes, how dare these people use their own alphabet.

trebor 13y ago
At least when your library is guaranteed to have ASCII functions and objects I can still type them. Otherwise non-ASCII libraries would be utterly useless to me.
- nolok 13y ago
  But that's a different problem altogether, being able to do my own code in my own language and making things I share properly accessible and usable to everyone. Also, you should note the recommendation I quote is not about adding the ability to use non latin alphabet, this is about removing that ability. It's been there for over a decade and I don't see that rendering libraries developers brainless, so I would say your point doesn't apply.

SixSigma 13y ago

to join in the other Unicode posts Utf is not Unicode https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-is-not-utf/ https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-i...

ohwp 13y ago

Sometimes I wonder how important backward compatibility is. A lot of <=PHP4 libs wont run on a modern server so there are already compatibility issues. Maybe PHP6 could be a complete cleanup. And maybe the focus shouldn't be on backward compatibility but on running <6 and 6 side by side.

dnzm 13y ago
Agreed. Backward compatibility is nice, but you have to draw the line somewhere.
frik 13y ago
They better keep the backward compatibility, or you face the fiasco of Python 2 vs 3. The way that PHP deprecate API functions slowly over a period of time is prefered.
- ohwp 13y ago
  Well I was thinking about Python when I wrote my comment :) One of the problems with Python is that they almost encouraged writing code in 2 and porting it to 3. Also: Python 3 is almost a complete different language. It would be the same when PHP6 would use a + as string concatenation. Such changes would turn it into a complete different language.
  - frik 13y ago
    Hopefully, PHP.net community won't go this route. The C-like syntax and the more or less stable code base (compatibility) are the main advantages over Python, Ruby, Go.
  - Pacabel 13y ago
    Have you ever actually used Python 2 and Python 3? Python 3 is not "almost a complete different language", as you put it. Somebody who has used both will notice that Python 3 is syntactically and semantically almost identical to Python 2 in most respects. The main differences are in terms of removing redundancy, removing outdated features and functionality, increasing consistency, vastly improved Unicode support, and standard library improvements. A developer with Python 2 experience should be able to pick up Python 3 in about 30 minutes, at the most. That's not what we'd expect were Python 3 "almost a complete different language".

jiggy2011 13y ago

The biggest hurdle I find in PHP at the moment is how difficult it is to get a debugger working. XDebug requires a bunch of installation and configuration and the PHP built in webserver doesn't seem to solve this problem at all. Most PHP programmers seem to have given up and resorted to using echo for debugging.

dnzm 13y ago
apt-get install php5-xdebug and enabling it in the config isn't exactly hard. Getting it to integrate with your IDE might be slightly more involved, but still no rocket science. It's also something you only have to do once, on your development box. So I don't really consider that a hurdle.
- jiggy2011 13y ago
  At which point it will happily ignore all of your breakpoints unless you invoke the right voodoo to make everything line up and do this every time you want to use a new system or VM for debugging. Total contrast to every other language where you don't have to think about this stuff.
- hrktb 13y ago
  This is true 90% of the time. From there, some libraries like ezpublish will cause all sort of problems with xdebug depending on where you put the breakpoint (it might be due to the number of recursive call or stack depth), and you'd really want to enable or disable debugging case by case, from your IDE ideally. Then debugging on a non dev server means installing a new package, configuring it and disable it afterwards just in case it has ill adverse effects. Then some eclipse pdt versions were stuck when using xdebug on some configs. Overall it works, but in practice, there's not enough cases IMO where step by step debugging is valuable enough to bother dealing with the not so exceptional weird things.
- porker 13y ago
  > Getting it to integrate with your IDE might be slightly more involved, but still no rocket science. Which IDE do you use? Granted, most of my issues come from the IDE vendor's browser extension, which only triggers debugging when there's an 'R' in the month... which is highly frustrating.

frik 13y ago

I see no "optional static typing" in the list. Would be great if PHP.net and HHVM (Facebook's HipHopPHP) would go on in the same direction (somehow).

chriswarbo 13y ago

The main pain-point I have with PHP is how clunky its functions are; it seems like first-class functions have only been added so they can tick a box on their feature list, since many aspects of PHP make them unnecessarily hard to use. Passing function names around as strings is, of course, a hideous consequence of using separate namespaces for functions (foo) and variables ($foo), so it's at least understandable. Having to explicitly list a function's free variables with "use" is a hideous consequence of not having lexical scope from the start, so again it's understandable. What I don't understand is why functions aren't first-class in PHP's parser. For example, the parser doesn't know that functions may be returned from other functions: $foo = function() { return function() { echo "Hello;" }; }; $foo()(); // Parse error Instead we have to perform some indirection like this: call_user_func($foo()); Or like this: $bar = $foo(); $bar(); Likewise, the parser doesn't realise that functions may be stored in objects: $baz = new stdClass; $baz->quux = $foo(); $baz->quux(); // Error, no such method Again, we have to add an indirection: call_user_func($baz->quux); Or $foobar = $bar->quux; $foobar(); Named functions can't be closures, even though we can declare them anywhere, presumably for historical reasons, ie. this is a syntax error: function foo($bar) { function baz() use ($bar) { echo $bar; } } Another example of making it unnecessarily hard to use functions is iterable objects, which can only be iterated via foreach loops (ie. there is no way to map, reduce or filter them). Of course, I could also complain about no tail-call optimisation, functions not being curried, etc. but those aren't PHP-specific since very few scripting languages seem to get them right for some reason :(

Udo 13y ago
You're right that the parser would benefit from some more work to make edge cases like $foo()() work correctly. It'd be the single most important feature for a 6.x version as far as I'm concerned.
- chriswarbo 13y ago
  It wouldn't need to be a version 6 feature, since it wouldn't break backwards-compatibility, but it may end up having to wait if that part of the interpreter is particularly gnarly (I've played with PHP's C code and I could see why it may be difficult!). Also, I'd hesitate to call "$foo()()" an 'edge case', since that implies that it's somehow different to any other function call. Making such a distinction is exactly what PHP got wrong here, ie. the parser should allow any expression to be called as a function, including other function calls and property lookups. Presumably there are two reasons why this happened: 1) Languages with first-class functions (and lexically-scoped closures) have fewer distinct features than languages without them; ie. functions are no longer distinct from other values (ints, bools, etc.), function names are no longer distinct from variable names (foo vs. $foo), methods are no longer distinct from properties ($foo->bar() could be a method call or a function call), functions and classes begin to overlap (lexical scope competes with instantiation and inheritance for resolving free variables) 2) For performance reasons, when these features were still distinct, they were branched on as early as possible, ie. in the parser. Essentially the problem is that the parser is still making distinctions which first-class functions have unified. The solution is to delay committing to these branches until further down the pipeline, ie. using a generic "expression" token, which "$foo" and "<expression>()" both parse to. The action to take can be resolved at runtime (when the value of the expression is known). In other words, there should be no difference between "<token>(<args>)" and "call_user_func(<token>, <args>)" (except maybe for things like pass-by-reference).

wcummings 13y ago

I can't wait for PHP6 to be released for the second time. I already own a book about it!

Thiz 13y ago

If only php changed concatenation from . to + and then used . for classes and packages I believe it would have a bigger impact. So honest question, what if somebody forked php and made those simple changes, how many people would switch? I would without hesitation.

krapp 13y ago
I wouldn't. I do find the use of . for concatenating strings to be annoying, but I wouldn't switch to a PHP fork that didn't also address bigger issues (saner function support, optional strong typing, named params maybe, operator overloading.) But then at some point you no longer have PHP you may have something which is close enough to an existing language that just switching to it becomes a more palatable option.
- Thiz 13y ago
  As a hobbyist and freelancer I don't use any of these 'bigger issues' (saner function support, optional strong typing, named params maybe, operator overloading.) for my casual projects. So no, I'd benefit the most with a cleaner syntax than with cooking unicorns in fairy sauce. And I believe 80% of casual programmers agree with me. Pareto wins.
  - aaronem 13y ago
    Syntactic headaches mean less than semantic ones. PHP fails to support, or supports quite poorly, many semantics which more competently designed languages handle well. If PHP is your primary, or worse your only, programming language, then this deficit leaves you at a disadvantage when it comes to growing more skilled in your craft, because after a while you're not learning new things which generalize across languages, but rather learning how to work around the famously irreducible piles of manure unique to PHP. You can get quite good at doing that, of course, and it's even a useful professional skill, there being so much PHP code in the world, and most of it awful. But doing so does not make you a better programmer, because at best it teaches you nothing useful about how to use less programmer-hostile languages, and at worst it inculcates habits which will prove actively harmful in any later effort to develop skills in such languages. That you are unable to appreciate this qualitative distinction does nothing to erase its existence, but it does provide an excellent example of the conceptual deficiencies which result from a PHP-centric perspective on programming -- even something as trivial as proper first-class functions you dismiss as "cooking unicorns in fairy sauce", and since PHP doesn't have them, how would you know otherwise? Whether you choose to address these deficits in your education is, of course, entirely your lookout. I'm just here to point out that they exist. You're free to argue otherwise, should you so choose, but you'll be wrong to do so; I speak here from experience gained in working with people who similarly mistook PHP for a worthwhile general-purpose web development language, who began their programming careers by specializing in it, and who in so doing unwittingly stunted their professional growth in precisely the manner I describe. Some overcame it, and matured into truly professional programmers with whom it was a pleasure to work; some did not, and most of those, as far as I've been able to keep track, eventually drifted out of the field entirely. All, having been seduced by that syphilitic temptress of innocents we call PHP, suffered unduly as a result. (I'd have been among them myself if not for early exposure to Perl, which for all its warts is a thousand times preferable to PHP; having cut my teeth on a language which is merely bad, I was equipped in my first encounter with PHP to recognize the legendarily awful when I saw it.) It's for reasons like these that, to borrow a quote from the UNIX-HATERS Handbook, "I'm rather surprised that [Rasmus Lerdorf] is still walking around alive"; indeed, long may he continue to do so, for if there's a special hell for programmers, then in its frozen ninth circle there must surely be a waiting hole in the ice with his name carved around the edge -- or, just possibly, a throne.