Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Since it's the holiday season now and everybody's making wishes, I wonder - which language features you would wish PHP would have added? I am interested in some practical suggestions/wishes for the language. By practical I mean:

  1. Something that can be practically done (not: "I wish PHP would guess what my code means and fix bugs for me" or "I wish any code would execute under 5ms")
  2. Something that doesn't require changing PHP into another language (not: "I wish they'd drop $ signs and use space instead of braces" or "I wish PHP were compiled, statically typed and had # in it's name")
  3. Something that would not require breaking all the existing code (not: "Let's rename 500 functions and change parameter order for them")
  4. Something that does change the language or some interesting aspect of it (not: "I wish there was extension to support for XYZ protocol" or "I wish bug #12345 were finally fixed")
  5. Something that is more than a rant (not: "I wish PHP wouldn't suck so badly")

Anybody has any good wishes?

Mod edit: Stanislav Malyshev is a core PHP developer.


locked by World Engineer Feb 23 '14 at 1:43

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Thomas Owens, Walter, Mark Trapp Sep 24 '11 at 7:47

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

@Stan: Much as you'd like to avoid that kind of comment, you're going to get it anyway. The problems people have with PHP are largely in the categories of things you're ruling out in your post. [...] – Fishtoaster Dec 19 '10 at 0:56
[...] You're saying "How can we improve the experience of getting hit in the face without actually not hitting you in the face?" I mean, yes, getting free coffee while we're being hit in the face might be nice, it doesn't really address a lot of the underlying problems with, well, being hit in the face. So, while I hope you get some useful answers here (as there already appear to be), don't be surprised by unproductive ones. – Fishtoaster Dec 19 '10 at 0:59
@Fishtoaster: if PHP associates with being hit in the face for you, by all means keep away from it. You are most definitely not interested in improving it. It so happens though there are people who are. This topic is for them, not for you. I'm sure this site has a lot of topics for you too, this is just not one of them. – StasM Dec 19 '10 at 7:57
I'm using getting hit in the face as an example- a situation where superficial improvements aren't that important; when most people's problems are with the underlying thing. I'm not even knocking your attempt to get suggestions for those superficial improvements- I'm just pointing out why you're likely to get a few unhelpful answers, given the situation. – Fishtoaster Dec 19 '10 at 8:23
@Fishtoaster: Not everyone, surprisingly, hates PHP - I have always liked it. Very flexible and quick (to code). – Orbling Dec 19 '10 at 14:52

64 Answers 64

I need some erlang features in php:

  • hot code loading
  • atoms
  • pattern matching (include name of functions, matching statement like: case of)

Working with bytecode: saving, loading, removing and so on...

Flexible embedding system


Expose zval reference count. (Yeah, we could use xdebug_debug_zval, but enabling Xdebug on a live site, ick.) Use case: active record object store - you have models which correspond to external resources (like database rows), and are responsible for modifying those resources. Having two separate object representations for the same resource would be bad (data loss due to conflicting writes and so on), so we need some sort of cache which can return the model for the requested resource if it has been loaded already. That would kill garbage collection, however: a last reference to the model object would always remain in the cache, so iterating through a large set of resources like a big DB query or a large directory would quickly eat up memory. This could be avoided if the object store could be check whether there is only a single reference to the stored object (the store itself) and destroy it if that is the case.

I see two problems with this: 1. relying on engine core implementation is usually a bad idea and 2. Calling function on a value increases its refcount, so it would never return 1. I guess you could do it with explicit refcounting though or by implementing it as PHP extension. – StasM Apr 17 '11 at 7:32
@StasM: how about weak references? That is a feature supported by a lot of languages, seems easy to implement, and makes it trivial to create an object store whose contents can be garbage collected. – Tgr Apr 20 '11 at 10:11

My number one feature would be

operators overloading

In my opinion, one recurring feature asked for here, namely native types as objects, can be fixed by creating your own wrapper classes. I have developed for my projects an arrayData object, a stringData object, an intData object, and so on... This solves:

  • Strong typing: since those are custom classes, they can be enforced
  • Type overloading: I can add whatever methods I need to my arrayData class
  • Type conversion: each of my classes has ->toArray(), ->toInt(), ->__toString() methods, and so on
  • html escaping in templates (strings are userStringData class that extends stringData class).
  • values are always passed by reference unless instructed otherwise
  • creating an intData('string') throws an exception.
  • etc (the list of benefits is still extremely long)

Imho, this is more beneficial than native types as objects, since you can have the exact number of methods you need, and call them to your liking.

But what I miss oh so much is the ability to use native operators on my objects. I am able to use the [] operator thanks to arrayAccess. But I can't use "+", "-", etc. If I could, then I could do stringData + stringData (equivalent to $string.$string), or stringData-stringData (equivalent to str_replace($str,'', $string)), or compare my types with ">" and "<="...
My current implementation uses $intData->add($n), $intData->substract($n), and so on. Cumbersome, specially in functions where you could expect either a native int or an intData object. Which means I have to check with instanceOf inside each function.

In other words, although my classes are ready, optimized and nice, until I can overload operators, they are not much more than a proof of concept. Using them in an actual project is annoying.

also, short-hand array syntax would rock – Xananax Jun 22 '11 at 5:56
I had not noticed this had already been requested (by MicE). I was sure to have read everything though. Well I hope at least my (more developed but more confusing) answer gives someone who has never thought of this feature some insight. – Xananax Jun 22 '11 at 13:44

Faster function calling

We have call_user_func($f,$a1,$aN), but it's been superseded with $f($a1,$aN). However, there's no such thing for call_user_func_array($f,$args).

My proposal is to create a specific language syntax for this, such as $f{$args}. The reason everyone should stay a mile away from call_user_func* is that they're extremely slow and ugly looking in the sense that there are better alternatives.

Object decleration syntax

Right now, to create an object on the fly, you need: (object)array('prop'=>'value');. By convention, we should also have object('prop'=>'value');. Also, short syntaxes would be handy, similar to JSON.

A be-all-end-all magic method for types

Right now, we have __toString(), and many suggested __toInt/__toFloat/etc. My advice would be to implement __toType() or __typecast(), which as a first parameter, the desired data type is passed, eg:

class Test {
    public function __toType($type){
            case 'integer':
                return (int)$this->age;
            case 'string':
                return $this->age.' years';
                throw new EUnsupportedTypeException();

If we wanted to be more specific, we could add another argument after $type, namely $class. So you can: if($class=='person')return new Person($this->age);

Specifying Data Type in foreach

Currently, you can specify the data type of a PHP function argument, like so:

public function say_hello_to(UserClass $user){
    $this->say('Hello, '.$user->name.'!');

It would be great to do this in a foreach as well:

public function on_enter_office(){
    foreach($users as UserClass $user) // <- See UserClass here?

The current "fix" is using a closure, like so:

public function on_enter_office(){
    $users->each(function(UserClass $user){

The fix takes more resources, more writing and messes the scope, hence why a native solution will make it easier, cleaner and probably faster than the current fix.

Conditional Defines

This probably won't be a useful feature for many people, but it is a great way to keep the running code at a minimum even when it is compatible with old systems, making execution faster. Consider the following code:

if(!function_exists('json_encode')){ function json_encode($value, $options=0){ // legacy code } }

  • The // legacy code section is still parsed, hence any errors in there will cause PHP to quit.
  • Parsing it also makes PHP slower, even if it doesn't need it at all.
  • The code is not intuitive to developers
  • Any IDE parsing engines will get confused since they ignore if statements and end up listing the function twice.

The fix? Conditional compilation:

function json_encode($value, $options=0){
    // legacy code

Not the answer you're looking for? Browse other questions tagged or ask your own question.