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.
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)
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.
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.
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.
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.
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?
While it's a good idea to look around what language A could borrow from language B once in a while, it's important to not fall into the trap of imitating B at all costs in A.
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.
Although I don't use it I have heard the symfony2 is one of the better MVC frameworks out there. The same people have also made quite a nice templating language called twig that you may also want to look at (http://twig.sensiolabs.org/).
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.
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).
PHP 5.4 does NOT introduce closures, they've been in there from 5.3.
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.
Multiple inheritance is a silly implementation of traits/mixins and interfaces. MI combines implementation and type inheritance but with traits/interfaces those concepts are separate and therefore it is much more flexible.
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.
nixle|14 years ago
SomeOtherGuy|14 years ago
ck2|14 years ago
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|14 years ago
It is unbelievably easy to build session support for other op-code caches. Here is my code for APC:
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.timdorr|14 years ago
randallsquared|14 years ago
notJim|14 years ago
mildweed|14 years ago
coenhyde|14 years ago
kemo|14 years ago
... and it will remain that way for a long, long time.
zombielifestyle|14 years ago
TomNomNom|14 years ago
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...
adaburrows|14 years ago
adaburrows|14 years ago
philjackson|14 years ago
I'm going to assume it's a backhanded insult and chuckle along.
unknown|14 years ago
[deleted]
Achshar|14 years ago
DonnyV|14 years ago
UPDATE Can you please stop down voting. I'm not hating on Php, read my other comments below.
darklajid|14 years ago
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.
phpnode|14 years ago
Regarding MVC frameworks, try Yii - http://www.yiiframework.com
Udo|14 years ago
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.
corford|14 years ago
unknown|14 years ago
[deleted]
Pedrom|14 years ago
[deleted]
sipefree|14 years ago
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|14 years ago
> ...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).
CWIZO|14 years ago
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.
zombielifestyle|14 years ago
* 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.
wvenable|14 years ago
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.
[1] http://en.wikipedia.org/wiki/Associative_array