
List of possible changes, updates, additions for PHP 6 - mariuz
https://wiki.php.net/ideas/php6
======
chriswarbo
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 :(

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

No, it's a clear avoidance of the problems of the Javascript lexical scope.
Yes, it'd be nice to have that "for free", but there's far worse that could
happen if you had free access to all variables. The GC complexity alone would
outweigh the benefit.

> Likewise, the parser doesn't realise that functions may be stored in
> objects:

A contrived example actually. First, the interpreter only interprets
"$foo->quux()" as a method call on a non-existent method. You are not
accessing a property of the object, ever, through a method call like that.
Instead, you have the option to implement __call.

    
    
        class foo {
            public $quux;
            
            public function __call($method, $args) {
                if (property_exists($this, $method) && is_callable($this->$method)) {
                    return call_user_func_array($this->$method, $args);
                }
            }
        }
    
        $foo = new foo;
        $foo->quux = function () { echo 'hello'; };
        $foo->quux();
    

Changing this behavior could single-handedly break compatibility with all
libraries making use of __get/__call methods. It could have been implemented,
yes, and probably should have been. However, most people using PHP aren't
throwing closures on an object (the closure won't have access to $this scope
till 5.4 or later, you know) and expecting them to work like a method.

I may address the other points later, but I'm pretty sure that if you'd take a
look and try writing idiomatic PHP you'd find it easier than assuming that
your idioms from other languages will work directly and without modification.

~~~
chriswarbo
> No, it's a clear avoidance of the problems of the Javascript lexical scope.

Do you mean problems with the way Javascript implements lexical scope (no
"let" blocks until recently, hoisting, global-by-default, etc.) or problems
with lexical scope in general? Lexical scope's been around since at least
ALGOL60, but really started to shine in Scheme.

I agree that there's a tradeoff for GC, and as I said it's understandable why
"use" acts the way it does, since lexical scope wasn't in there from the start
(where it could have informed other scoping policies).

> A contrived example actually.

I agree, but it's contrived precisely _because_ PHP's OO and functional
features don't play well together, so everybody's learned not to do it.

> First, the interpreter only interprets "$foo->quux()" as a method call on a
> non-existent method. You are not accessing a property of the object, ever,
> through a method call like that.

That's exactly my point! :)

> Instead, you have the option to implement __call.

Yes, this is a decent workaround for a self-contained library/app/etc. but it
shouldn't really be necessary.

> Changing this behavior could single-handedly break compatibility with all
> libraries making use of __get/__call methods.

That's an issue, but I don't think it would be as calamatous as you say :) It
would mainly alter behaviour for those who are putting functions in their
objects, but as you say that's not commonly done!

> However, most people using PHP aren't throwing closures on an object (the
> closure won't have access to $this scope till 5.4 or later, you know) and
> expecting them to work like a method.

I wasn't saying that a function property should act like a method
_semantically_ (ie. be called with an implicit $this argument), only that it
should be possible to call it like a method _syntactically_ , ie. the syntax
"A(B)" should call "A" with arguments "B". Note that it's not just functions;
quux could be anything callable.

> I'm pretty sure that if you'd take a look and try writing idiomatic PHP
> you'd find it easier than assuming that your idioms from other languages
> will work directly and without modification.

I've been writing PHP since 4.2, so I'm perfectly aware of what does and does
not work. I'm pointing out what _could_ work, and make PHP much nicer.
Sticking to standard practice is a good idea when writing libraries and
applications, but is stifling when brainstorming for a new version of PHP.

My problem with idiomatic PHP is that it's usually _incredibly_ verbose,
usually because everything's been collapsed down to be first-order, which
leads to boilerplate (eg. repeated build-up and tear-down code) and copypasta
("multiply_all_foos" and "sum_all_foos" which are the same except for the
operator, or "Foo->multiply" and "Foo->sum" if you prefer). A few higher-order
functions, like function composition and partial application, can cut down
this bloat tremendously. It's just jarring when this bumps into a completely
unnecessary PHP quirk, like having to put "call_user_func" all over the place
;)

~~~
trebor
> Do you mean problems with the way Javascript implements lexical scope (no
> "let" blocks until recently, hoisting, global-by-default, etc.) or problems
> with lexical scope in general?

In general. It's powerful to be able to reach out of your immediate scope to
access something outside it, but then everything from the defining scope must
be retained for later. Because of variable variables, which can be either
wickedly difficult to debug or incredibly handy, virtually anything from the
defining scope could be accessed in a way the interpreter couldn't predict.

In some ways, I can already see the mess that could ensue. Which is precisely
I appreciated the "use ()" syntax.

> I wasn't saying that a function property should act like a method
> semantically (ie. be called with an implicit $this argument), only that it
> should be possible to call it like a method syntactically, ie. the syntax
> "A(B)" should call "A" with arguments "B". Note that it's not just
> functions; quux could be anything callable.

I guess I can see the value in that. However, that leads to ambiguity during
debugging, especially if you've included a dependency and haven't thoroughly
vetted it. In that case, you need some XDebug magic to know if $foo->quux was
a closure, callable array or string, invoke-able object, or a method. Then you
need to determine its call semantics, etc.

I don't think "anything callable" is appropriate. But I do think anonymous
functions, closures, and invoke-able objects are. You could then make strings
and arrays invokable by wrapping them in a class, but without trying to
execute an erroneous string or array.

> I'm pointing out what could work, and make PHP much nicer.

Yeah, your suggestions could work. Whether it would make PHP better or worse
depends on the programmer, and the change's second-order effects on how the
object model works. But I'm skeptical of its benefit. It would probably wind
up muddying the execution logic till at least 1 patch level further. I'd have
to see some real-world examples of how this would be useful to fully convince
me.

Call me paranoid if you wish, but I wouldn't want a novice programmer
stumbling on that change by accident. I can already envision the spaghetti
they'd use it to write, then we'd have to come bail them out. ;)

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

~~~
Pacabel
It's not so much the degree of difficulty, but rather that the difficulty
exists in the first place.

The PHP experience is absolutely horrible compared to those of Java, Python,
the .NET languages, and even to those of C, C++ and Objective-C.

Take Java, for example. Debugging works seamlessly in pretty much every major
Java IDE, including the free ones, on pretty much every platform used for Java
development. This has been the case for a decade now, if not longer. It takes
basically no effort to start debugging Java code.

The .NET experience is even better, although more limited in terms of tooling.
Debugging is stupidly simple and very efficient when using C# and Visual
Studio. Again, it has been like this for many years now.

PHP needs to get its act together so that debugging is at least as simple as
it is when using those other languages and runtimes. Anything less is just
plain unacceptable today.

~~~
thaJeztah
+1 if debugging is present out-of-the-box, even first-time users will have no
excuse _not_ to use proper debugging.

While installing XDebug may be no rocket-science, I've encountered too many
situations that it just didn't work reliably, causing developers to revert to
nasty var_dumps() for debugging.

~~~
ygra
The only things I managed to get working reliably with xdebug were

• break at the first line in a script (very annoying when you have to debug
something very deep)

• generate tracing logs (horrible to read but the best debugger replacement I
had at the time)

• generate profiling logs (very helpful)

I never managed to get arbitrary breakpoints to work so I basically resorted
to either traces or var_dump.

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

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

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

~~~
Pacabel
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".

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

------
nikic
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 ;)

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

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

~~~
mikegioia
This went from "insightful" to "rant" pretty quickly. I was with you until
"mistook PHP for a worthwhile general-purpose web development language".
That's exactly what PHP is, a worthwile general-purpose web development
language.

I understand your grievances with PHP's semantic issues, and I can appreciate
that PHP's lack of support for newer, common language paradigms inhibits
growth in professional development.

But you replied to a guy who starts his comment with "As a hobbyist". Most of
what PHP is used for is for small web development projects that in no way need
optional strong typing and full functional support.

At the beginning of your comment you say that if PHP is your only programming
language than this deficit leaves you at a disadvantage. Well no shit! There's
no silver bullet language that can do everything for everyone 100% of the
time. In one breath you lambaste using PHP as your only language; in another
you identify that PHP's lack of support for x, y, and z cause the developer to
stagnate in learning new things. It seems you condemn using PHP for
everything, and then are upset that it can't do everything!

To this I would say use the right tool for the job.

~~~
aaronem
You seem to see "insightful" and "rant" as mutually exclusive. I don't agree,
but that's merely a quibble; to address the meat of your response, I say that,
while of course you're right that no language is ideal in all cases, PHP
exists in a unique local pessimum compounded of its attractiveness to novice
programmers and its unmatched ability to hamper them from learning lessons
they will find useful in becoming familiar with languages other than PHP --
indeed, it is far more successful at making it _harder_ , not easier, for
novices to gain a grasp of any other language, and it is precisely this trap
which incurs my loathing.

Small web development projects, as you say, do not require strong typing,
first-class functions, &c. But they certainly can in many cases be _improved_
by these capabilities, and, in any case, few languages which offer them
outright require their use; meanwhile, a language which either fails entirely
to offer them, or worse offers a broken, awful version of such functionality
to newbies who are not equipped to recognize such enormities and are thus
vulnerable to the fallacy that that's how such things are and should be done
everywhere, is one which can inflict enormous harm on people who frankly don't
know enough yet to look out for themselves -- precisely the sort of people, in
other words, which PHP so successfully attracts, through its presentation as
the right tool for _every_ web-facing job.

Perhaps you mistook my colorful phrase, "that syphilitic temptress of
innocents", for mere hyperbole, and failed to recognize it as the precise, if
metaphorical, description which it is. If you have so mistaken me, then I hope
this comment helps to clear up the matter somewhat.

~~~
mikegioia
Haha, ok fair enough. I agree with everything you just said. I honestly wish
PHP _would_ implement these features and break backwards compat for those same
reasons.

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

------
SixSigma
to join in the other Unicode posts

Utf is not Unicode

[https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-i...](https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-
is-not-utf/)

------
thomasfoster96
They had me at "Unicode support".

Assuming it somehow works.

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

------
jmnicolas
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 ?

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

