Staking our future on PHP

I believe that the growth of PHP depends increasingly on applications like Drupal, Joomla!, WordPress, phpBB, Typo3, ezPublish and similar systems. Specifically, I believe that most organizations adopt PHP primarily because they want to use one of these popular applications which have PHP at their core. Fewer organizations adopt PHP because they want to build from scratch their own PHP applications. Hence, more than ever, the future of PHP depends on popular PHP applications that have emerged over recent years.

Conversely, the future of Drupal depends on PHP. Moreover, many of us are staking our future, and that of our businesses, on Drupal and, by extension, on PHP. The same is true for those who make their living with Joomla!, WordPress, phpBB, vBulletin, Typo3, and ezPublish.

It seems that we have arrived at a point in which there is a symbiotic relationship between PHP and the most popular PHP applications. A relationship that did not exist when PHP was created. Symbiotic relationships are obligatory: we depend entirely on each other for survival. And yet, I feel like we've been living apart. It makes sense for us (i.e, application developers) to contribute to the development of PHP, and for the PHP core developers to work more closely with the developers of the most popular PHP applications.

Having spent ten years of my life developing Java Virtual Machines and run-time systems, I feel that I'd be able to contribute to PHP. Unfortunately, I don't currently have time for it. Maybe when Acquia is a bit larger, we'll hire a full-time engineer to contribute to PHP's development. Maybe other organizations will consider doing the same, or more people will find the time to be active in more than just one project. It seems as though our future would really benefit from such people.

If you could contribute to PHP core, what would you change?


Larry Garfield (not verified):

On the language level? Runtime extension of objects and/or classes, and some sort of integrated event system (a la Drupal hooks or Javascript events). There was a recent proposal for formal properties on objects (with intrinsic getter/setter logic) that I thought was quite interesting, too.

On the process level? Add a process. Really. Drupal is a formal, structured, and military-precision development process compared to the unstructured mess that the PHP internals development process is. I've periodically considered getting into PHP development (i.e., developing the engine), but then I realize the politics involved and just sort of sigh and wander back to the Drupal issue queues.

Which is said, because Drupal could really benefit from having a few C-savvy developers on hand who could extend, or at least help interpret and understand, the PHP engine.

Damien McKenna (not verified):

Probably everyone's #1 complaint: function naming and argument conventions - is there an underline in the function name, is the needle before the haystack or vice-versa, etc.

Gareth Price (not verified):

Damien beat me to it, PHP's (anti-)conventions drive me crazy.

But then, Drupal also has that issue... securepages vs google_analytics for example.

Plenty of precedent for technologies that maintain their popularity because they provide a framework for higher level things.

moshe weitzman (not verified):

Lets not derail a potentially productive conversation with minutia like this. Yes, it is annoying. These things happen in Drupal too. When you care about backwards compat, it is hard to clean up these things.

I think Dries is thinking more along the lines of contributing to PDO. PDO is heavily relied upon by Drupal now, and its dev community is on life support AFAICT. APC might be another candidate. If that were in core PHP, we could make some helpful assumptions.

Larry Garfield (not verified):

Yes, beefing up PDO would help a lot, especially for the non-MySQL drivers. I know DamZ suggested that some of what DBTNG does in its own extensions really should just be PDO feature patches, and I agree. More schema independence would help with performance, too.

If we could reliably say that APC in a certain configuration was always available, that would allow some very interesting performance optimizations. However, that debate has been going back and forth with no clear resolution in the PHP world for literally years. That's not a technical problem but a social/political/process problem, as I noted above. That's very much a "sh*t or get off the pot" type problem, and one that needs leadership within the PHP internals community that it has actively avoided having.


I'm not sure consistency of APIs is minutia. Like Damien, I'd love to see an API that is more consistent and predictable. Furthermore, this strikes me as something that can be fixed relatively easily as the old API could remain.

Jeffrey (not verified):

I totally agree that function parameters/naming conventions in PHP are, at best, confusing. It may not seem like an important matter but it IS a matter that puts people off in regards to PHP usage, regardless of the system built on it. And that could have a negative impact on the adoption of any systems that are based on PHP. It IS a symbiotic influencing matter. IMHO, mind you.

But, yeah, backwards compatibility issues would be painful to think about.

Brian Moon (not verified):

"many of us are staking our future, and that of our businesses, on Drupal and, by extension, on PHP"

And then saying:
"I feel that I'd be able to contribute to PHP. Unfortunately, I don't currently have time for it."

Those two statements are conflict with one another. If your business (i.e. mortgage, food on your table) relies on PHP that much, you should make time for it. I am active in several open source projects that our business relies on. I have to be. I know how the internals of the daemons we use work. I have fixed bugs, added features and helped others on mailing lists with no direct benefit for my company. But, in the end, when I needed a bug fixed, I had clout and karma with the maintainers. I have a voice in the open source projects that my business relies on. Don't discount that benefit.

mherchel (not verified):

So, in that case, you have time to contribute to Linux, Apache, PHP, and Drupal? Not to mention any other Open Source applications that you may need?

Jakub Suchy (not verified):

I would change the processes regarding releases of major versions + security involvement. I didn't like how PHP 5.2 was deprecated after all major PHP applications staked their future on it.

Tyrael (not verified):

- just as Larry said, a formal release/development process
- LFS support
- unicode support
- refactor/continue pdo
- refactor the error handling (generating full backtrace and such for every error, which are just gets discarded/ignored, etc.), replace fatal errors with catchable fatar errors where appropriate
- stackable error handlers
- stackable exception handlers
- "fix" the current autoloader
- upload progress bar (I think APC provides this.)


chx (not verified):

Consistent parser. See how array dereferencing needed to be added -- and then it was added as a new parser state :(

Honest approach to backward compatibility. I have been yelled at for telling the team that PHP is already not backwards compatible just pretends it is and much good would arise from shedding this pretension as it would allow some much needed cleanup.

Of course runtime extension of objects and/or classes is something we badly miss.

Although the typing system makes this hard, some way to discern between 32 and 64 bit integers when necessary. If I could ask the tooth fairy then I could use 128 bit integers too.

Expose compiled pregs (I guess that'd be a resource).

I will try think on more but that'd be it for now.

Nils Adermann (not verified):

All the big projects you point out have a plugin system of some variety. As Larry mentioned these systems could benefit significantly from language level support of events and runtime extensible/composable objects. I think traits are getting us somewhat closer to that, but more work in that direction is needed. E.g. some syntactic sugar for delegating all function calls while implementing the delegate's interface (doesn't work with __call) would simplify the runtime composition of objects.

sdboyer (not verified):

Big +1 to this. Lack of good language features for common, essential OO patterns means we have to implement those in userspace, which means uncomfortable overhead.

Yorirou (not verified):

There are plenty of things what I really miss. The first thing is a normal scope system. Functions defined in functions should not be global, the function should see the variables in a higher scope.

An example:

function makeCallback($fixedVar) {
  return function($callbackArgument) {
    return someFunction($fixedVar, $callbackArgument);

The second thing is functional programming idoms. There could be immutable variables (with a different notation than $, or using a keyword like "final") and pure functions (with pattern matching, guards and tail recursion). Sometimes it is much easier to express problems with these set of tools.

Here is an example of a possible syntax:

pure function foo(int $X, $Y instanceof Bar) when $x > 1 {
  $Z = $Y->baz(),
  $Z * $X
pure function foo(float $X, $Y instanceof Bar) when $x < 1 && $x > 0 {
  $Z = $Y->baz2(),
  $Z / $X

This would also allow us to define partial functions, so improper arguments will be caught by PHP, and not as notice or "Warning: invalid argument supplied to foreach" 10+ function calls deeper in the call stack.

Philip Paeps (not verified):

Have you considered that many people won't touch your software with a bargepole precisely because it's written in PHP? No competent security-conscious sysadmin will allow PHP on his systems.

Perhaps it's time to implement Drupal on more solid foundations?

If everyone else abandons PHP, maybe that's a hint to find something else rather than to try to fix the unfixable?

I always wonder why "web people" insist on toy platforms like PHP and why everything must have a SQL(ish) database bolted on? Is it really that difficult just to write it in C and to operate on real data? I've been hacking operating systems, device drivers and other low-level things my entire carreer, so maybe I have a skewed view of the world but ... really, it's not *that* difficult.

Maybe it's time to embrace a completely different plaform. Take the higher level constructs that work and plug them on new foundations. Foundations that have been proven solid and that are known to be able to stand the test of time.

Tyrael (not verified):

"Maybe it's time to embrace a completely different plaform. Take the higher level constructs that work and plug them on new foundations. Foundations that have been proven solid and that are known to be able to stand the test of time."

You mean Cobol?


Larry Garfield (not verified):

No competent security-conscious sysadmin will allow PHP on his systems.

Uh. Have you looked at the web lately? PHP is the most widely used server-side web language by a wide margin, and runs such "security conscious" sites as Yahoo, Facebook,,, the King of Belgium...

I don't know why you need your fancy C, anyway. Real Men(tm) code directly in assembler. None of this toy compiler stuff.

Translation: Yes, your view of the world is really skewed. Unless you're writing operating systems, device drivers, and other low level things there's decidedly few reasons to code in C these days, and many many many reasons not to. (Manual memory management is not for the faint of heart. I used to code in C, too.)

As for migrating Drupal to another language, impossible. Drupal is architecturally tied to PHP language semantics (hooks are a language hack, essentially). And in the 4 years it would take us to reimplement Drupal in some other language, rearchitecting it along the way so it would even work... we've lost 4 years of development time in which we are not innovating. That's suicide.

PHP has "been proven solid and is known to stand the test of time." After 15 years, it is ubiquitous on the web (including security conscious servers and sysadmins) and the "new wave" languages like Ruby and Python have failed to unseat it, much as they like to laugh at it and try to do so. Sure it has warts, but so does any other language.

trouble (not verified):

> Uh. Have you looked at the web lately?

Honestly, I try not to. It's a depressing mess. Used to be a great way to find information about a variety of topics. Then it went through a period where all you could find were pictures of people's cats. These days, it's a breeding ground for opinionated people unhindered by any recognition of facts. It's hard to fit in.

> I don't know why you need your fancy C, anyway.
> Real Men(tm) code directly in assembler. None of this toy compiler stuff.

C is just ANSI assembler, isn't it?

> Translation: Yes, your view of the world is really skewed.

Probably just my view of "the web". I guess it's a bit like working on sewage systems. After a while, the smell just goes away.

> (Manual memory management is not for the faint of heart.
> I used to code in C, too.)

I never found it a problem. You mainly need to understand how computers work and apply the syntax of the language accordingly. At the end of the day, pointers are just numbers and computers are really good at counting. All you need to do is tell them what to count.

I wonder if the "security conscious people" tasked with running those websites you mention sleep well at night. Surely they keep their "web servers" far away from any important systems they have to manage.

marcvangend (not verified):

You mainly need to understand how computers work and apply the syntax of the language accordingly.

You make it sound really easy, but don't forget about the thousands of Drupal contributors who don't understand exactly how a computer works (or understand jokes about Cobol), and still write modules and patches. The community needs those people.

Anonymous (not verified):

PHP is out, so you immediately jump towards C? With its pointer madness, developer-hostile syntax and most importantly: abysmal handling of text, one of the most elementary data types in a CMS? The right language for this job needs excellent support for Unicode, regular expressions, collation and all that other messy stuff that balloons simple ideas into hundreds of lines of C code.

A C program is a very strict description of the underlying algorithm, down to each individual byte of memory used. This is great for device drivers and the like, but is simply overkill for most code when reasonable default assumptions can be made instead. It may not be hard to do for a seasoned developer, but it is still a waste of time when in a higher level language the code is shorter, easier to read and equally performant for all practical use cases.

As for "real data"... that's a matter of perspective. What matters is how data is stored and handled. The world of C is as rife with buffer overflows as PHP has SQL injections, so clearly this is not just an issue of language.

That said, PHP is clearly a messy, slow and outdated language and there are tons of excellent alternatives available. I agree that a rewrite should not be an outlandish idea for people who are serious about evolving Drupal. Dries' outlined goals for each Drupal release have never been met for years now, IMO because most require herculean rearchitecting of Drupal core and nobody wants to do it.

trouble (not verified):

> PHP is out, so you immediately jump towards C?

It's just the language I happen to be most familiar with and the language most reasonably complex systems are written in. Feel free to substitute Ada, Java or whatever floats your boat.

> With its pointer madness, developer-hostile syntax

I don't find the syntax of C developer-hostile at all. I'm also told that PHP's syntax borrows heavily from C, so I'm not sure what the problem is. As for pointer "madness": pointers are just numbers. If you're going to get anything done with computers, you should probably understand call by reference. No doubt PHP has a similar concept, and I'm sure it also boils down to a number in the end. Pointers are nothing to be afraid of.

> and most importantly: abysmal handling of text, one of the most elementary
> data types in a CMS?

C has no problems with text. In fact, text is mostly opaque to C. This gives the programmer the freedom to treat it in any way that makes sense to him. If text is your most elementary data type, surely you can engineer a good solution to handle it well.

> The right language for this job needs excellent support for Unicode

Unicode is just one possible representation of text. It is as well supported in C as in any other language and is mainly a function of how the programmer deals with it. The language does not place any constraints on how you deal with your text.

> regular expressions, collation and all that other messy stuff that balloons
> simple ideas into hundreds of lines of C code.

Hundreds of lines of C are nothing to be afraid of. I agree that C requires the programmer to express what he wants very precisely, but this precision strikes me as the point of the exercise. Computers are really stupid machines that just do what they're told. Surely if you can tell them precisely what you want, rather than going through multiple layers of obfuscation, the results will more closely approximate what you really want?

But it's clear that the views of "operating systems people" are incompatible with those of "web people". I don't think either of us is going to convince the others of his views so we'll just have to agree to disagree.

Anonymous (not verified):

I'd hate to say it, but yes, you've been stuck in C land for far too long. In my experience, people who are so precise about "what they really want their computer to do" are neurotic about the wrong things and confuse matters of taste with technical superiority.

Unicode is not just "another representation" and text being opaque to C is not a good thing. This is simply your abstract programmer view of the world being at odds with reality. Handling text is messy, complicated, and involves a lot of meat-space rules. Collation, case conversion, character counting... good luck doing that with your opaque strings. There is a reason most C programs treat Unicode as crazy future tech to stay away from. And STL might give you a pristine, universal string representation independent of the underlying character type with a minimal amount of copy operations, but it doesn't make it any easier to solve the real world problems instead of the problems programmers have created for themselves.

But, you seem to have deliberately ignored my main point. The purpose of a developer is to produce a piece of working code. If the problem is such that the assumptions of a higher-level language are sufficient, then what's the point in going to C, especially when you'd need a much better programmer to achieve just the same level of algorithmic sophistication and safety of operation... never mind something better?

Ben Jeavons (not verified):

A step in the right direction? How many Drupalers are going to, The PHP Community Conference next week?

Barry Jaspan (not verified):

Performance optimization. The (admittedly simplistic) benchmarks I've seen of PHP versus other scripting languages (e.g. Perl, Javascript, etc) make it clear PHP's performance is horrible.

effulgentsia (not verified):

Among other ones, Barry might be referring to this simplistic benchmark I shared with him last year:

$t0 = microtime(TRUE);
$x = 0;
for ($i=0; $i<1000000; $i++) {
function addone($x) {
return $x+1;
$t1 = microtime(TRUE);
print ($t1 - $t0);

takes 1.89 seconds to run on my Macbook Pro. The absolutely equivalent code in JavaScript:

var d0 = new Date();
var x = 0;
for (i=0; i<1000000; i++) {
function addone(x) {
return x+1;
var d1 = new Date();
alert(d1 - d0);

takes 5 milliseconds (on Firefox). If anyone tries this and finds substantially different results, please share.

Ok, the JavaScript number makes sense. On a 2GHz processor, that's ~10 clock cycles to iterate a for loop and call a function that does a simple arithmetic operation. Pretty damn decent for a scripting language.

PHP, on the other hand, is 400x slower! This is killing us, especially in the drupal_render() / theme() pipeline, where we do lots and lots of primitive operations and function calls on every tiny element that makes up a page. It would be so awesome if we could have rule-based manipulation of render arrays, similar to jQuery selectors. But with a language that's 400x slower at this type of stuff than what jQuery is written in, I don't know how we'll do it within acceptable performance parameters.

So, yeah, if anyone reading this has some time to devote to delving into PHP internals, finding out why primitive operations are so slow, and fixing that, it would be truly awesome.

Note, it's not that PHP is 400x slower than other languages at everything. If it were, it wouldn't have survived this long as a language. But being slow at primitive operations, like calling a function, really hampers some of our Drupal architecture.

Brian Moon (not verified):

That is some awesome FUD effulgentsia. For starters, your JS there does not even run on FireFox, so, this is clearly not the code you benchmarked. I fixed it though and ran it.

I added to the example code. I added a second loop that does not use the function call to discover if it is the loooping or function overhead that is causing so much grief. Of course, as I figured, your supposed benchmarks are complete FUD.


This code runs in 850ms and 530ms for the two parts in Firefox 4. Hardly 5ms you claim.


This runs in 400ms and 137ms. Both beat your claim of 1.89s on your MacBook (because you know, I always run high traffic web sites on a MacBook)


For fun I wrote the code so that it would run in NodeJS. Now, that is fast. 27ms for the function call loop and 18ms for the loop without the function call. Still, nowhere near your 5ms claim of Firefox.

So, based on this, you need to rewrite the Drupal render phase using V8, the javascript libarary NodeJS is built on top of. It is nice and fast. There is even a hook in PHP to run V8 code.

Being serious, is PHP the fastest language in the world? No, but we already knew that. Function overhead in PHP is bad. It has been for a long time. It is better now than ever. Don't use tons of function calls. It's that simple. If you are calling functions in your template layer, you have dug your own grave. The render layer should be all echos, ifs and loops. Do all that hard work when you are building the arrays of data and your life will be easier. You will still spend half your time in render. You can't get around it.

Lastly, how about real examples. No one loops 1 million items in a render phase. At least, no one that really is worried about performance.

effulgentsia (not verified):

Hi Brian,

Wikipedia defines FUD as "a strategic attempt to influence public perception by disseminating negative and dubious/false information designed to undermine the credibility of their beliefs.". That was not the intention of my comment. I do not wish to undermine PHP, or frameworks built on it. In this blog post, Dries asks "If you could contribute to PHP core, what would you change?". My answer is "improve the speed of primitive operations like loop iteration and function calls".

I'm not sure why my original code example didn't work for you. It works for me in FF 3.6, FF 4, Chrome 11, and Safari 5 on my Mac. Perhaps I should mention that the way I run it is by creating an .html file whose contents is simply that code, wrapped in a SCRIPT tag.

Anyway, your JS example works just as well, and breaking it out into two examples to isolate the function call overhead portion is great. Here's what I find on my Mac:

Firefox 3.6: 4, 4
Firefox 4: 5, 10
Chrome 11: 17, 17
Safari 5: 45, 39

So, different JavaScript VMs have different characteristics. On what OS do you see 850ms and 530ms?

You also bring up a good point that a MacBook does not make for a good production web server. I ran your PHP script on a DreamHost account, and found 570ms and 100ms, which more or less matches your results, but still demonstrates a 100x difference between function call overhead in PHP vs. JS (except, apparently, JS in your OS's Firefox).

The idea of running V8 code from PHP sounds intriguing. When I have a chance, I'll play around with that. If it demonstrates significant performance gain, that may provide for a way to build some render layer improvements.

Finally, as to the adequacy of the example, of course, the Drupal render layer doesn't invoke 1M function calls within a single loop. But drupal_render() is a recursive function that invokes several functions during its operation, and operates on many page elements. This architecture allows for modules and themes to have a lot of opportunities to customize what gets rendered and how. You may argue that given PHP's function call overhead, we should be calling fewer functions. But I argue the opposite. To make the render system more approachable to front-end developers, we should add jQuery like selectors to Drupal's render arrays, and doing so may require more internal function calls being needed. So, thanks again for the tip on looking into V8.

catch (not verified):

This is an important discussion to have. We have a lot of documented workarounds for PHP bugs in Drupal core, but they're not often linked to upstream issues, and like others here I find the PHP development process a bit confusing and impenetrable.

While I'm saying 'we' here, most of these are on my personal @todo list (only some are actually in progress sadly).

  • We should gain a better understanding of the various APC configurations and how they impact different kinds of Drupal sites (I came across apc.lazy_classes and apc.lazy_functions only a few weeks ago, they're undocumented, can't find any benchmarks published, and haven't had time to do my own). Whether or not we can rely on APC entirely, we should not be making changes to core that try to fix issues that APC already handles without very good reasons, knowing exactly why we're doing that, what benefits or side-effects it will actually have.
  • We could pay closer attention to PHP extensions for other technologies important to Drupal (for example the memcache/memcached extensions, MongoDB).
  • Would be good to see more work done on getting Drupal to run on HipHop (which I believe is still blocked on a PDO issue).
  • Would be good to see more work on the Drupal-specific pecl extension.
  • Do we know of other PHP CMS or frameworks that have closer links to the core PHP development community (Symfony? Kohana? - I don't know which is why I'm asking), if so how are they managing this?
  • There's work going on to integrate better with the jQuery too (at least, to clean up our JavaScript so it doesn't make jQuery developers weep). jQuery is obviously a very different community from PHP, but it's also one we have a dependency on, even if it's a touch looser than the dependency we have on PHP.

Overall I think the Drupal project has grown to the point where it's become much harder to keep up with just things going on with Drupal, while it's also getting more important to keep up with the ever increasing list of technologies we rely on.

mike (not verified):
  • Remove OO. It just adds complexity to the language that most people abuse unnecessarily. Drupal got how far without it? (sans Views...) The hook design negated the need for object extending and overloading. Bravo on that. One of the main strengths in my mind in Drupal, and a model of how you can still do everything procedurally. Except now in 7 it's moving more OO :(
  • Remove namespaces. It just adds confusion. Prefix your functions, don't abuse global variable namespace.
  • Standardize needle/haystack order issues.
  • Standardize function naming (underscores)
  • Thinner core. Not as many things bundled in. Rely on PECL/etc. Easier to release core when there is less having to be packaged. Make almost everything pluggable, and easy. Including bytecode catches. Bundling APC is neat, I am all for less options, but there's reasons others exist too.
  • Add in named parameters.
  • Resolve the WSOD annoyances.
  • Full UTF-8 in and out.
  • Integrate Suhosin/hardening patches as needed.

Overhaul it somewhat like Drizzle did with MySQL. Throw out the years of crap, make it more efficient.

And for Christ's sake people, stop making "What PHP Can Learn From Java" type blog posts. If you want Java's strong suits, use Java. Stop trying to bastardize what was originally created as a C-style language to adopt things like namespaces, object oriented stuff, etc.

Do you know how much garbage, overkill code I see because people take their OO learnings and think they need to apply them to a simple website? How many hours of digging through crap code it takes to fix their mistakes? Just stop it already. Keep things simple. Your life will be easier, your clients' lives will be easier, your websites won't have as many annoying bugs or odd bottlenecks. #procedural'tilidie

Jeffrey (not verified):

PHP needs to be many things to many people. Keep OO in.

Vingborg (not verified):

Apart from most of the many excellent suggestions already made, I have one that would really make my Drupal life easer:

Sane array literal notation!

E.g. $form = ['#type' => 'checkbox', '#title' => 'Something']

This is pure syntactic sugar, for sure, but I wager that no Drupal developer will miss the implications.

Sadly, this is not going to happen anytime soon. It has been suggested on at least three different occassions in the last decade -- with fully working patches and all -- but every time it's been shot down due to ... eh ... well, I really don't know. It's un-PHP-ness or something?

Bram (not verified):

I just read your post about web services ( and that remembered me of the trouble I had implementing a SOAP web service last year with PHP (see for example: Maybe those problems are solved by now, but otherwise improving the quality of the SOAP libraries could be useful I think. In the increasing inter-connectivity of applications this could be a very important step for D8.

Jeffrey Griffiths (not verified):

2 things we've run across that have caused problems in a high-performance environment:

1. PHP session implementations can cause problems with locking when you use clusters. We've actually gone with cookies and a compare -and-swap system instead. In particular our attempts to use simple session data with multiple Memcached servers revealed problems.

2. LAMP is the most common deployment platform, but each Apache -> PHP -> MySQL connection locks a process / worker because everything is executed synchronously. A possible option would be to implement asynchronous event-based programming in PHP, similar to JavaScript. I can't imagine the sort of flame wars that would occur on internals if someone seriously proposed this though ;).

Goran Rakic (not verified):

Cast variable into inmutable or const, very usefull when passing objects references into function, if they should not change. This should be property of a reference, not of a object pointed by the reference.

Support full function/method overloading, both by number of arguments and different typehint. Like hello(Cat $x) and hello(Dog $x) or hello(Cat $x, $y).

Oscar Merida (not verified):

Or instead of relying on overloading, use Interfaces so that Cat and Dog both implement the "Hello" interface and then the code that uses those objects can just do $x->hello($y) or $x->hello()

Jeffrey (not verified):

Memory usage. Under Apache, httpd threads that serve authenticated Drupal users can take up a hella'lot of RAM.

While RAM costs for equipping a webserver have become absurdly inexpensive in comparison to a few years ago, it still seems like there is a big overhead for PHP threads.

Or, admitting some ignorance here, is this just an Apache mod thing and the problem isn't specifically in PHP?

bob (not verified):

Open source does not mean you have to develop like a bunch of kids playing soccer. The ball is kicked in one corner and everyone rushes over to it. Another kid kick the ball to another corner and everyone rushes.

We have zend taking a 'how can we make money approach' to php. What the PHP community needs are several BDFL's that take leadership and turn PHP into a language corporations will adopt. (Yes we know about how this could fracture the community, so do it in a way that doesn't). The BDFL's should do whatever they can to turn PHP into a language they're proud, in turn us developers can be proud of it too.
Take for example the name space issue, it should not have been begrudgingly agreed upon and forced on the community. The BDFL's could have implemented their preference and let the better version work itself out in the community (Here's to :: or :::, but not \)

Agree on conventions - eg. naming, arguments

Steal any conventions from java that give php the perception of being corporate ready. eg. use similar class names if you have to, camel case, what have you.

Beautify the way php is written. eg. short pieces of code should look elegant, both on the code side and the template side, at least can we get <?php ?> to not suck up whitespaces at different times so the outputed html looks the way we expect?

Everyone who uses PHP sees the clusterf**K that is the c++ standardization process. 10+ years to agree? The same factors are occuring with PHP and we all see it. The community needs to act like PHP is a startup and release major versions YEARLY.

There shouldn't be a fear that if you remove something, you're going to piss a few people off. The fear should be that if you don't do things correctly for the long term, you're going to hurt new adopters and people who spend years working in a language they despise.

Christopher (not verified):

Except for a few interesting comments about adding things like event support -- you can see the problem with PHP development. Most of the comments are personal peeves, such as naming or syntax, that have wasted time in these discussions.

I would recommend looking at things that frameworks and major projects all have to reinvent:
- Events are a good example of this.
- Dispatch and routing might be handy for the many controller based solutions.
- Caching is another common functionality that should be added. Note that Symfony2 uses Zend_Cache. Perhaps that is closing in on a standard solution.
- Probably every project wraps PDO with similar additional functionality. Identify the common additions and enhance PDO.

Tgr (not verified):

Low-hanging fruit:

  • Clean up naming conventions.
  • Expose zval reference count. Currently it is impossible to implement an object cache without killing garbage collection, and coding active records without object caching is a world of pain.
  • Named function parameters. I am amazed 20 years after Python PHP still doesnt have them.

Not-so-low-hanging fruit:

  • Make static functions callable with a non-static syntax.
  • XSS detection support, for example string tainting.
Jason Flatt (not verified):

I see this same relationship in Drupal. Drupal contrib authors using Drupal core w/o participating. There is the symbiotic relationship there, as well (evidenced by the number of contrib modules that get slurped into core).

If I could change something in Drupal core, what would it be? Do I even want that responsibility? Would it even matter? Would anyone care? Would I be able to make any headway, or would I just get squashed or ignored? Those thoughts are in my mind constantly.

My ultimate response to myself is the same as you: if I had more time, I would contribute more to Drupal core. I would probably do it even if I was squashed or ignored, because I know someone would benefit from my involvement, even if it was to copy a snippet of code to use it else where.

The thing is that lately I've not had the time to properly maintain my contrib offerings adequately, which is also important. So that's where I'm currently focusing my thoughts and energy.

I do have other ideas I would like to implement, but right now they're waiting for me to get through my stack of have-tos before I start on the want-tos.

Enough blathering. Time to get back to work.

grendzy (not verified):

If you could contribute to PHP core, what would you change?

Big things: Clean up the needle / haystack junk and other inconsistencies. As chx said stop pretending to be backwards-compatible (one of the really bad outcomes of this pretense IMO is OS vendors don't package older releases). A "taint" bit on strings.

Little sugary things: Negative array indices and range indices (like python). Fixed precision arithmatic (for example I found it basically impossible to implement MurmurHash in PHP). Keyword arguments.

David M (not verified):

I'd like:
1) keyword arguments like Python (this is riddled with naming convention issues, I know, but I like it anyway):
: function manyParameters($first, $second, $third=0, $fourth=0) {}
: manyParameters('first var', 'second var', $fourth='fourth var');

2) better ability to spawn/spin-off a process/task -- not sure this is possible with PHP's 'integration' into the webserver, but it'd be nice nonetheless

Larry Garfield (not verified):

Forking to multiple processes is not possible in the web server, because the process is managed by Apache, not PHP. Doing so causes much hilarity to ensue.

On the CLI, it works decently now. I'm working on a project right now where I do some setup work and then fork into multiple processes to do further number crunching and iteration. (Essentially batch processing in multiple processors.) The model is based on the Unix process forking API. Not perfect, but gets the job done with just a little bit of extra wrapper logic.

Jeffrey Griffiths (not verified):

Not everyone uses Apache Larry! IMO mod_php and pre-fork is something that holds PHP back from getting truly exceptional ops/second on single server. PHP-FPM with Nginx is the first step forward in this regard for many many years, but it still doesn't address how PHP <-> MySQL calls are completely synchronous. At least with FPM you're not locking up a big fat Apache process at the same time.

Imagine if you could make a database call in PHP and supply a callback to be executed on return?

Larry Garfield (not verified):

You're talking about async event callbacks a la Javascript, in particular node.js. That's not what David M was talking about. He was talking about process control, which is something else.

Process forking in a web server is a recipe for disaster, IMO. async event callbacks I already listed above in my first comment as something I'd like to see in PHP, but I don't now how feasible it is without gutting and rewriting the engine.

Darrel O'Pry (not verified):

I'd cleanup and modify the stream handling to properly parse URLs when selecting the stream handler, and probably try to optimize the stream handlers...

unfortuately the bug I filed immediate got a wrongful RTFM... and hasn't been touched since.