
What to Look For in PHP 5.4 - robmorgan
http://jburrows.wordpress.com/2011/12/17/what-to-look-for-in-php-5-4-0/
======
nixle
Nice to read something constructive and informative besides all the hate PHP
has been getting lately.

~~~
SomeOtherGuy
What do you mean lately? PHP has gotten tons of well deserved criticism since
it was created. It isn't "hate" to point out that a popular language is much
worse than many other comparable languages.

~~~
rickmb
It becomes "hate" when the criticism is ill-informed and largely irrelevant.
The bits of PHP that are "much worse" are mostly either legacy cruft that
nobody in their right mind uses anymore, or bits are rarely touched in day to
day programming but are safely wrapped in frameworks, ORM's, libraries
etcetera.

Beyond that, PHP simply isn't particularly elegant (mostly since it was never
really designed to be a programming language), and we all know it.

Other than that, I rarely see any relevant criticism, let alone constructive
criticism.

~~~
eropple
Nobody can hate something as strongly as somebody who's spend way too much
time looking at it. That, in this case, would be me.

Those frameworks and ORMs that you claim as a panacea are generally
obfuscatory at best (Symfony2, which is a brilliant example of what you can do
with PHP and a cautionary tale of designing a system that makes sense to
twelve people, ever) to downright maliciously bad (CodeIgniter, get the hell
out of my universe and take Joomla with you).

If you can muddle along with glacially inefficient frameworks (often with APIs
that make core PHP seem not all that terrible for a time) and ORMs
(personally, I don't use an ORM for anything, and credit where credit's due,
PDO is actually a very reasonable solution), more power to you, but some of us
(hi) have already been to that dance and realized it wasn't going to work for
us. So I do criticize PHP on many fronts, from its psychotic language
decisions to it's slapdash internals and it's blatant encouragement of idiotic
programming practices. (You can say "nobody in their right mind would use
that," but the existence of crapfloods of shitty PHP-- _hello_ , Wordpress--
suggest that either that's not the case or the biggest PHP projects out there
are run by lunatics.)

If I end up writing PHP, invariably I end up grabbing Silex and building the
useful bits on top of that. While doing so, I continually wish it was a
language where imposing actual application structure wasn't essentially
_actively discouraged_ ; the outright necessity of shit like call-by-name
loses what little error-checking you can otherwise get and the solution to any
data storage problem seems to be "MORE ARRAYS!". PHP is a tool where a
sufficiently advanced developer finds themselves fighting it as much as using
it, and that is a shame. Because it doesn't _have_ to be willfully obnoxious.
It just is.

I mean, I went back to Java for my own projects, over continued bashing at
PHP. That is a low bar. (But, to be fair, Play makes Java tolerable.)

~~~
Joeri
"If you can muddle along with glacially inefficient frameworks (often with
APIs that make core PHP seem not all that terrible for a time) and ORMs
(personally, I don't use an ORM for anything, and credit where credit's due,
PDO is actually a very reasonable solution), more power to you, but some of us
(hi) have already been to that dance and realized it wasn't going to work for
us."

Count me in as someone who took a look at the frameworks and said "no thanks".
I think where the frameworks fail is that they always feel the need to go OO.
PHP's design is pretty procedural in essence, because it's not a lot more than
an HTTP wrapper with some useful procedures you can call. If you wrap that in
an OO layer, by necessity you have to complicate things. I've found the best
use of objects in PHP is in support of procedural request handler code. The
only framework I use is ZF, because you can easily use it without buying into
the whole MVC and routing paradigm.

~~~
Getahobby
Woah, in one sentence you claim about PHP devs feeling the need to go OO and
then the next sentence you extol the virtues of ZF? ZF is all OO, all the
time.

~~~
SomeOtherGuy
He already answered your question in the post you are replying to:

>because you can easily use it without buying into the whole MVC and routing
paradigm

As much as I think the zend framework is terrible, you can pick and choose
whatever bits of it you like and ignore the rest. There's no working around
assumptions or anything, it is just a normal way of using the framework.

------
ck2
Has anyone tested the three opcode caches with the 5.4 release candidates?

I am depressed that eaccelerator seems to be fading away - they removed their
shared memory functions for their build with 5.3 support.

In my experience eaccelerator is slightly faster and more stable than xcache.
As a bonus, when it did have working shared memory functions (under php 5.2)
it has session handler support so sessions are done completely in memory
(added: without any additional code or modification)

~~~
maratd
> it has session handler support so sessions are done completely in memory.

It is unbelievably easy to build session support for other op-code caches.
Here is my code for APC:

    
    
        if(extension_loaded('session'))
        {
            function ses_open($path, $name)
            {
                return TRUE;
            }
    			
            function ses_close()
            {
                return TRUE;
            }
    			
            function ses_read($id)
            {
                return (($GLOBALS['session'] = apc_fetch($id)) ? $GLOBALS['session'] : FALSE);
            }
    			
            function ses_write($id, $data)
            {
                if(!isset($GLOBALS['session']) || $GLOBALS['session'] != $data)
                {
                    if(apc_exists($id))
                    {
                        apc_delete($id);
                    }
                    return apc_store($id, $data);
                }
                else
                {
                    return TRUE;
                }
            }
    			
            function ses_destroy($id)
            {
                unset($GLOBALS['session']);
                return apc_delete($id);
            }
    			
            function ses_gc($max)
            {
                if(
                    ($apc = apc_sma_info())
                    &&
                    ($apc['avail_mem'] / ($apc['num_seg'] * $apc['seg_size'])) < 0.25
                )
                {
                    return apc_clear_cache('user');
                }
                else
                {
                    return TRUE;
                }
            }
    			
            ini_set('session.save_handler', 'user');
            session_set_save_handler('ses_open', 'ses_close', 'ses_read', 'ses_write', 'ses_destroy', 'ses_gc');
        }
    

The only problem is that this still requires you to compile the session
extension. I am looking into ways of working around that, since it's not
really used for anything except re-direction.

~~~
ck2
How exactly would you use this with third party code executing on the server
that cannot be modified?

eaccelerator's session handler (was) simply built in and requires no
modification, just add the one-word setting to your php.ini

~~~
maratd
You can't modify your code, but you can modify your php.ini?

OK.

PHP has a very nice feature where you can automatically prepend (and append,
if you want) a file to all requests. Create a single file, modify your
php.ini, done.

I am not telling you that eaccelerator isn't amazing. I am showing you how to
get around problems you may run into if you end up using a different op-code
cache.

------
randallsquared
Link didn't work for me, but [http://jburrows.wordpress.com/2011/12/05/what-
to-look-for-in...](http://jburrows.wordpress.com/2011/12/05/what-to-look-for-
in-php-5-4-0/) did. Not sure why the date would have changed to earlier.

~~~
notJim
I think this may have been posted prematurely. Even in the version you linked
to, it seems like part of the traits example has been cut off.

~~~
adaburrows
It's been fixed. I found the correct revision and restored it with the right
date. The original link works again.

~~~
robmorgan
did I submit the right one?

------
mildweed
I've been waiting for PHP to use traits my whole professional career as a PHP
dev. Super excited they're here now.

~~~
coenhyde
Yeah, the lack of traits/mixins were the biggest problem with php's object
model.

------
kemo
I still think PHP is good enough. Not the best, the fastest, the safest or the
coolest but - good enough.

... and it will remain that way for a long, long time.

------
zombielifestyle
Closure::bindTo gives a nice js-like feeling, but i wonder why the hell a
invocation of a closure in a class member triggers a warning.

~~~
TomNomNom
Class/object members and methods do not share a "namespace", so it's possible
to have a method and a member with the same name. If you assigned a closure to
a member that had a colliding method, PHP wouldn't know which one to execute.

I'm guessing this is at least some of the reason for that behaviour.

You _can_ force it to work in the absence of a collision by using a __call
override. An example of which can be seen here:
[https://github.com/TomNomNom/Talk---New-stuff-in-
PHP-5.4/blo...](https://github.com/TomNomNom/Talk---New-stuff-in-
PHP-5.4/blob/master/10-mungeable-objects.php)

~~~
zombielifestyle
Didn't think of that, pretty obvious now. ty :)

------
adaburrows
I fixed a spelling issue using the iPhone app. For some unknown reason it
published an earlier version. It has the same content, but a different date.

------
adaburrows
I just edited the date manually. The original link is back up.

------
philjackson
What to look for in PHP 5.4: 404 Not found.

I'm going to assume it's a backhanded insult and chuckle along.

~~~
Achshar
its a 404 for me too!

------
DonnyV
I'v been thinking about using Php lately. I come from a C# background, so I
was poking around to see what I would be missing or gaining from Php. Why
haven't they added a compiled option yet? I know you can use
<http://phpcompiler.org> compiler to do it but why hasn't it just been added
to the project? The speed increase is well worth it. Also I noticed Php
doesn't have generics or Template classes. I use these a lot in my C#
libraries. Anyone know if thats going to be added anytime soon? I do like that
its used everywhere. Also looking for a good MVC framework for Php like
Asp.net MVC.

 _UPDATE_ Can you please stop down voting. I'm not hating on Php, read my
other comments below.

~~~
phpnode
I too wish php had a widely supported compiler, but in reality it's not
something that most projects require. The overhead of interpreting php is a
lot lower than e.g. making a single db call. Also, in the most common usage
scenarios, PHP processes only live for the time it takes to deal with each
request, so how do you approach that if you're compiling your code? Keep
spinning up new processes or rewrite your application code?

Regarding MVC frameworks, try Yii - <http://www.yiiframework.com>

~~~
DonnyV
These speed charts are why I would compile Php.
[http://naspinski.net/post/AspNet-vs-php--speed-
comparison.as...](http://naspinski.net/post/AspNet-vs-php--speed-
comparison.aspx) It seems worth it too me.

Thanks for the Yii link.

~~~
phpnode
those charts don't say whether APC is enabled, which leads me to suspect that
it isn't. APC is an opcode cache that greatly enhances php performance, no one
runs a high traffic website without using APC

~~~
DonnyV
Did not know about APC...nice. Does APC just compile it after the first time
and save it in memory? Can you use APC to create a packaged compiled file?

~~~
zombielifestyle
bytecode caches (like APC) store the bytecode on the fly in memory. you can't
create somthing like a "binary" file.

edit: at least they're not intended to create "binaries". you can probably
mess around with APC and make php look and behave like a compiled language.
but you won't gain any notable speed improvements beyond the on the fly
caching.

edit2: you can store php projects in a jar like file, caller phar.
<http://php.net/phar>

------
sipefree
It's been a long time since I had any interest at all in PHP, and these new
features make me feel uneasy once again.

The development server seems like the only good thing about it.

Traits looks like a silly implementation of multiple inheritance mixins, with
a 'use' keyword that doesn't really fit in with the language itself. And the
whole 'insteadof' thing looks weird. It will lead to hackish code for many
people, encouraging weird monkey-patching.

The author says "when stored in an array", then proceeds to use
"$functions['anonymous']". That's not an array. Sigh. I know PHP likes to call
them that, but I just find it weird that they would continue to insist on mis-
naming two of the fundamental data types of computer science.

The introduction of closures can only be a good thing, and a lot better than
the passing of a string name of a function as a callback argument from before.

As usual though, it's expected that most servers and frameworks won't get the
update for some time, due to whatever backwards incompatible changes have been
made.

I know it's all the rage to hate on PHP these days, but even giving an
objective look at the state of the language, given the thriving ecosystems of
its competitors, makes it look to me like something I would never touch.

~~~
j_col
I don't think that PHP referring to hash maps as an array is a bad thing, in
fact I've always loved the flexibility of the overloaded array implementation
in PHP.

> ...due to whatever backwards incompatible changes have been made.

PHP is normally very good that way, does anyone know of any backwards
incompatible changes that have been made?

> I know it's all the rage to hate on PHP these days, but even giving an
> objective look at the state of the language, given the thriving ecosystems
> of its competitors, makes it look to me like something I would never touch.

Yes you're right, it is quite fashionable to hate PHP and has been so for the
~10 years I've been using it, but who cares it gets the job done (a language
for the pragmatists not the purists).

~~~
sipefree
> I don't think that PHP referring to hash maps as an array is a bad thing, in
> fact I've always loved the flexibility of the overloaded array
> implementation in PHP.

But they're not arrays. JavaScript and Lua do the same thing, allowing you to
assign numeric or hashed keys on objects (or tables in Lua), but they don't
call them Arrays, because they aren't. Arrays have expected behavior and
implementations. So do hash maps. It's fine to amalgamate them, just give it
the right name.

> PHP is normally very good that way, does anyone know of any backwards
> incompatible changes that have been made?

I haven't looked at any in this version, but recently there was an article (I
think on HN) complaining about severe ABI changes that required all compiled
modules to be recompiled, leading to adoption problems.

> Yes you're right, it is quite fashionable to hate PHP and has been so for
> the ~10 years I've been using it, but who cares it gets the job done (a
> language for the pragmatists not the purists).

I used PHP for many years as well, and for that reason I don't think it's a
language for the pragmatist at all. It's not expressive enough, it encourages
bad coding, and it doesn't have an ecosystem comparable to Ruby, Python, or
even the amazing one Node.JS has managed to garner in the past year or so.

~~~
randallsquared
_But they're not arrays. JavaScript and Lua do the same thing, allowing you to
assign numeric or hashed keys on objects (or tables in Lua), but they don't
call them Arrays, because they aren't._

PHP's arrays combine both vectors and associative arrays, but both numerically
indexed arrays and associative arrays _are_ types of arrays, are they not?

 _Arrays have expected behavior and implementations. So do hash maps. It's
fine to amalgamate them, just give it the right name._

Whether associative arrays use hash maps underneath is an implementation
detail, not fundamental to the interface PHP provides to [associative] arrays.

