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.
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 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)
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');
}
eaccelerator's session handler (was) simply built in and requires no modification, just add the one-word setting to your php.ini
... and it will remain that way for a long, long time.
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...
I'm going to assume it's a backhanded insult and chuckle along.
UPDATE Can you please stop down voting. I'm not hating on Php, read my other comments below.
1) You're hijacking the thread with something unrelated and better suited for some online research or sites like SO
2) According to your questions you're not investigating PHP, you're looking for C# in disguise/in another set of clothes.
Regarding MVC frameworks, try Yii - http://www.yiiframework.com
PHP isn't just orders of magnitude slower than JIT-ed or native compiled languages, but it has no affordances for that fact. There's no standard way to run code in the background. Zend won't start working on one either, because they sell a jobs queue as part of their Zend Server product.
Frankly, a JIT-ed PHP is the only feature I need. I appreciate the syntactic sugar added in the last few revisions of PHP, but honestly, I'd trade every new feature since PHP 5.2 for a bit more speed. With stuff like closures and traits it seems like they're working on the easy stuff instead of the necessary (but hard) stuff.
Thanks for the Yii link.
In this specific case, I don't think it's a good idea to do C#/ASP.Net in PHP and vice versa. Most PHP hosting environments do have a compile-once-run-many-times paradigm by virtue of opcode caching. The advantage over a typical Java or .NET app server is that you can change files and they get automatically recompiled on the fly. So for all intents and purposes, PHP is usually running a piece of in-memory compiled bytecode.
There are many MVC frameworks for PHP, for any interpretation of "MVC" you might want. I'm sure you can find one that's closely modeled after ASP.net, but again I'm not sure this is a productive undertaking in principle.
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.
> ...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).
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.
As for traits, sure but as with all things it depends on who will use them. Some will make a mess out of them, while other will use them properly. Just as with any other feature in any other language. Please stop using this tiered "reason" for why PHP is bad. It's just doesn't hold water.
* array? yeah, it's called like that. it could even be named "fridge" or "smartass".
* due to the new release process php BC is guaranteed for non major versions. adaption will be fast.
* thriving ecosystems don't matter, PHP is just one possible piece in the toolchain.
The 'use' keyword already exists in PHP for use with namespaces; it's pretty common for C-based languages to overload common keywords.
As far as I'm aware, there are no backwards incompatible changes in this release and servers have been tracking the most recent PHP versions much better these days.
Also, array[1] is the correct terminology.