What to look for in PHP 5.4: 404 Not found. I'm going to assume it's a backhanded insult and chuckle along.
its a 404 for me too!
What to Look For in PHP 5.4
31–40 of 67 posts
Re: What to Look For in PHP 5.4
#32Has 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 co…
> 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'])) Re: What to Look For in PHP 5.4
#33Earlier quoted context omitted.
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.
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 programm…
>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.
Huh? The article in question demonstrates otherwise, note they just now fixed one of the problems with anon functions, a relatively new feature. PHP continues along the path of adding "features" randomly and without even understanding the purpose behind the feature, and so you get half-features that kinda work and don't really solve any problem in the context of PHP, but were just added so they could check off "some feature we don't understand" on the feature list.
>Other than that, I rarely see any relevant criticism, let alone constructive criticism.
In the context of PHP, I think "you should use a better language" is as constructive as you can really get. There's nothing wrong with warning new web developers that PHP is worse than every other language that lives at the same sort of level (perl, python, ruby, pike, etc).
Re: What to Look For in PHP 5.4
#34Earlier quoted context omitted.
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 obje…
> 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…
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.
Re: What to Look For in PHP 5.4
#35What to look for in PHP 5.4: 404 Not found. I'm going to assume it's a backhanded insult and chuckle along.
[deleted]
Re: What to Look For in PHP 5.4
#36Has 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 co…
> 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_writ…
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
Re: What to Look For in PHP 5.4
#37Has 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 co…
You should be using APC. It has all the shared memory functions you need and a lot more momentum than eA ever had. Facebook was even hacking on it for a while before HipHop was developed. It's a much better product overall.
Re: What to Look For in PHP 5.4
#38Earlier quoted context omitted.
> 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_writ…
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
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.
Re: What to Look For in PHP 5.4
#39Earlier quoted context omitted.
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.
When that "well deserved criticism" comes from the same people who feel compelled to post in every PHP thread, obsessively, over and over again ... it's hate. Hate isn't inherently negative. You can hate evil, etc. However, if you hate a programming language ... there's really something wrong with you. It suggests a very sheltered life. There are far more important things in life that deserve your hatred.
I think something that forces me, almost daily, to waste my time dealing with problems that are simply nonexistent in more sane languages deserves my hatred. (And I have a LOT of hatred for it!)
Re: What to Look For in PHP 5.4
#40I 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.