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.

  • 9
    @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
  • 24
    [...] 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
  • 5
    @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
  • 5
    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
  • 6
    @Fishtoaster: Not everyone, surprisingly, hates PHP - I have always liked it. Very flexible and quick (to code). – Orbling Dec 19 '10 at 14:52

63 Answers 63


Annotations for PHP would be great, One feature that would stand out for upcoming years. This feature will help to write big frameworks with clean code.

  • 1
    The problem is to figure out what "annotations" means for PHP. I definitely don't like Java ones, they are (as most things in Java) hugely complex and serious overkill for 90% of tasks. We have some other languages too so maybe we'll find suitable model. – StasM Dec 19 '10 at 8:01

Don't get rid of short open tags, specially the echo one =(. This:


...is way better than this:

<?php echo $myvar;?>
  • 2
    Actually, most of the time it should be <?= htmlspecialchars($myvar); ?>. It's a shame that PHP doesn't have shorter syntax for safe HTML output. – Kornel Dec 27 '10 at 0:18
  • Are they getting rid of that? I thought it's just a configurable option and always will be...? – Dan Rosenstark Dec 29 '10 at 9:16
  • They are now off by default. Check this thread out: stackoverflow.com/questions/2413661/…. The thing is that they might get deprecated, and then possibly removed. – dukeofgaming Dec 29 '10 at 9:20
  • 1
    And you don't get the point. Try reading a template/vew file with a hundred of these vs. a hundred of <?php echo $var ?>. I can macro it, typing it is not the point, reading it is. – dukeofgaming Dec 31 '10 at 1:02
  • 1
    Even <?php=$myvar?> would be a step up from the long syntax and shouldn't interfere with XML. Or perhaps a Smarty-like syntax {$myvar} . – DisgruntledGoat Jan 6 '11 at 17:36

I would like to see an else clause for while, for, and foreach. E.g.:

while (/*condition*/) {
   /* display each result */
else {
   /* condition was never true; display "no results found" message */

The else block is only executed if the condition for the while was never true.

This would make it so you wouldn't need to keep track of Boolean flags, and perhaps it could help you think about boundary cases and possible error conditions.

  • Can't you just do this? if (!condition) { /* no results found */ } else while (condition) { /* do whatever */ } – DisgruntledGoat Jan 6 '11 at 17:38
  • @DisgruntledGoat: Then you repeat the condition code (which, in addition to creating software maintenance troubles could be executing a tricky call more times that necessary). – Macneil Jan 8 '11 at 1:03
  • true, but then the condition should be as simple as possible. Even if you're calling a function, it can usually be determined ahead of time if it will run once or not, e.g. looping through SQL results - you can check the number of rows first. – DisgruntledGoat Jan 9 '11 at 14:58
  • @DisgruntledGoat: In that case it would be better to use the flag solution instead, which at least has no repetition of code. – Macneil Jan 9 '11 at 17:16
  1. I'd one day like to see data type, however -- I also like the simplicty of not having to deal with data types, this is a double edged sword for me.
  2. namespaces!
  3. Overload function calls with different method signatures
  4. Better support for unit testing and code injection, PHPUnit is an amazing tool, as well Symfony code injection framework does wonders... however they all come with their own learning curve.
  • 1
    4. better in what way? – StasM Dec 17 '10 at 21:20

Definitely method overloading using type hinting to differentiate the method signatures. Even further, I would like to see some kind of ASP.NET style "attributes", so that my controller actions in a PHP MVC framework could look like this:

/* [HttpGet] */
public function login() {}

/* [HttpPost] */
public function login() {}
  • 1
    if you do $foo->login(), how do you know which one of those gets called? – StasM Dec 17 '10 at 21:46
  • 4
    You could always just call them login_get and login_post. A framework can then key off of those names instead of the proposed attribute. – Justin Ethier Dec 17 '10 at 21:56
  • 2
    Actually, that code would not be valid in C#. Instead, you'd have something like [HttpGet] public void login() and then [HttpPost] public void login(string name, string password). The attributes don't change the fundamental rules of the language. – davidtbernal Dec 18 '10 at 15:50
  • To further elaborate, HttpPost means the method is only available for a post request. Even if someone makes a get request with matching arguments, they would receive a 404. If someone makes a post request with no arguments (referring to my example), they would also receive a 404. This functionality is implemented at the web framework level, not the language level. The only role the language has in this is supporting attributes. – davidtbernal Dec 18 '10 at 16:14

Allow to namespace a file from the include call, something like this

include('mytemplate.php', 'MyNamespace');


include 'mytemplate.php' use MyNamespace;

And start allowing us to import ("use") namespaces without prefix:

use OtherNamespace as self;

(instead of having to import each individual class in order to use it without a namespace prefix)

  • Yes please I would love this. include 'class.php' in NameSpace; – Petah Dec 28 '10 at 6:55
  • Non blocking SQL Queries (Like insert some log, but don't wait for result of query)
  • Parallel SQL Queries

just a dream

  • 2
    This can be solved by DB features like MySQL's insert delayed. What you're really looking for is asynchronous statements. – Jé Queue Dec 21 '10 at 14:50
  • ext\MySQLi already supports this, although it's poorly documented. I did test it (in a very narrow scope) however, and it works :) – Mchl Dec 28 '10 at 16:45

That would be nice to have the possibility to set the primitive type (bool|boolean, int|integer, float, double, string, object) of a parameter in a method as array is allowed.


  • current:

    class HttpResponse {
    public function __construct($version, $statuscode = HttpStatus::OK, HttpResponseHeaders $headers = array(), $body = '');


  • hope:

    class HttpResponse { public function __construct($version, integer $statuscode = HttpStatus::OK, HttpResponseHeaders $headers = array(), string $body = ''); }

I thought also to have an Assert static class that can be useful.


Generators. As in Python, with yield.

  • 1
    I wonder if it's possible already, having closures and iterators... – StasM Dec 25 '10 at 2:03
  • it depends of some internal secrets. For example, if foreach does operate on Iterator directly or (like in case of array) on its copy. After all, there is no difference between Generator and iterator, apart of syntax which permits to use yield anywhere => you can use ordinary function as a generator – ts01 Dec 25 '10 at 4:41
  • how about this: php100.wordpress.com/2010/01/27/ruby-iterators-in-php – StasM Dec 25 '10 at 9:36
  • Cool, and kinda slow - you are creating a new instance of RubyIterator for every item. It's indeed a very good reason to have constructs like that built-in into the core – ts01 Dec 25 '10 at 9:53
  • no, it doesn't create new RubyIterator for every item in the loop, look closely. The iterator is created once when each is called. It still probably will be slower (since it's in PHP and not in C like core constructs) but not that much... – StasM Jan 18 '11 at 7:48

Ability to throw exceptions in __destructor or __toString. And, really, is there any explanation why it is not possible?

  • 1
    Yes, there is. Dtor may be called in random moment in unrelated code, so there's no reliable way to catch such exception. As for toString, the problem is probably more technical - it would lead to too many checking in various conversion routines. – StasM Dec 25 '10 at 2:05
  • For destructor, if exception is not catched (ie raised after die() or when object is destroyed by gc) it could simply make "Uncaught Exception" error. But even if I can (hardly) understand such a limitation for destructor, not having this possibility for __toString suggests rather serious design flaws in ZE. – ts01 Dec 25 '10 at 4:02
  • That's what should happen for dtors now, see bugs.php.net/47143. toString is bugs.php.net/bug.php?id=53648, still open. We'll get to it one day :) – StasM Jan 18 '11 at 7:51

support for type hinting for all types, and _toXXX magic methods for every type possible. (php common usage drifts IMHO rather to limit type juggling /with some exceptions, such like convertion float<->int/)


PHP needs an immutable Unicode string class. Ensuring input strings are valid, normalized UTF-8 and that it stays valid should be trivial.

$str = new Utf8String('āll īs ōk');
$str = $str->ucwords(); // Āll Īs Ōk
$str = $str->strtolower()->toAscii(); // all is ok
(string) $str; // UTF-8 bytes

I made a prototype based on PHP-UTF8.


It seems that nobody mentioned an optional  type safety.

It would be great to be able to write code like this:

$someVariable = 123;
$someVariable = "Hello World";

int $anotherVariable = 123;
////$anotherVariable  = "Hello"; // This must cause runtime exception.
////int $lastVariable = "World"; // This must cause it too.

Another example:

// Current style (which must remain).
function SayHello($howManyTimes)
    if (!is_int($howManyTimes))
        throw new Exception('Argument $howManyTimes is invalid. An integer was expected, instead of ' . gettype($howManyTimes) . '.');

    echo str_repeat('Hello', $howManyTimes);

// New, optional, style, allowing to have a shorter code.
function SayWorld(int $howManyTimes)
    echo str_repeat('World', $howManyTimes);

SayHello("Hello World");

////SayWorld("Hello World"); // This must cause runtime exception.
  • lexical scope for lambdas (using another keyword then function) (or block syntax to create an proper lexical scope?)
  • make lambdas in object properties callable
  • always imply semicolon with lambda closing braces
  • fucking add use() for normal functions!!
  • traits
  • ability to intercept instanceof / is_a()
  • generators
  • open up Exception for runtime modification
  • a function to check against interfaces without implementing it

adding object wrappers for extensions using resources (curl, ftp, gd2 ... ). Like

 $oFtp = new Ftp();


  • I agree, this would allow these to me mocked very easily in unit tests. – MicE Dec 31 '10 at 14:08
  • you can do it now, writing generic resource wrapper. But it hits performance – ts01 Dec 31 '10 at 16:34

and, obviously, get_shutdown_functions() and unregister_shutdown_function(). Currently there is no way to acces that. And more generally, some abstract support for callback stacking - something to unify spl_autoloads, shutdown functions, error handlers (currently not stackable, but maybe...) etc. Kind of register_callback($callback, $stack) and so on , with some predefined stacks ('autoload', 'shutdown', 'error' ...) called by php or by user itself.


My first two annoyances has not to do with PHP, but with its implied usage conventions.

  1. 'The file name extension' for library code (e.g. PEAR/Horde/Zend/etc.) should end on .phps instead of .php. The benefit of this is that it clearly separates code to run and code to include, as well as that optionally all (your) code is pretty readable/browsable from the server. As a bonus, spl_filename_extensions() can be used in your autoloader for other's convenience.

  2. The convention (in the documents) is that :: is used for both static as well instance methods, I would be thankfull if they would use :: for static and -> for instance stuff. As a good convention there still will be room for error concerning interpretation, but it's at least more clear.

To name a few, I would also like to see the following:

  1. Reflection*'s getDocComment (or perhaps another variant of the name or argument) should be more liberal and also get just the first comments (until space) above the mentioned type. In other words: I don't like the verbose (read: line eating) doccomment while I really just want to be able to provide the bare minimum in any kind of commenttype: //, #, or /* ... */.

  2. List of used namespaces, e.g. getdefinednamespaces().

  3. The behaviour of 'undefined constants' should be changable by an ini directive, e.g. an empty string or fatal error. Nevertheless, it should never be implicitly transformed to a string! (it's like the ; in javascript).

  4. The constant __CLASS__ should also automatically work like this (called statically) stdClass::__CLASS__ == '\stdClass'. In other words, instead of referring to a class by a string, I want to use a class and its magic constant __CLASS__ to refer to it. (yes it is an idefix)

  5. Type casting and magic methods __fromType($instancetype) and __toType($type). So an object can be casted to an integer: $y = (int) $x or to another object $y = (BeanWrap) $x. Nevertheless, an implementation of this means that of the twelve available casts which cover eight different types, the names of these casts can not be used as classnames (e.g. int, binary, boolean) anymore.

  • Are you sure that __toType($type) is better than __toString, __toInt, etc? It makes code less readable (think all that switches inside). And if one conversion, ie to int, is not supported? And how can you validate return type in that case? And concerning __fromType($instancetype), how do you know target type in this case? – ts01 Dec 27 '10 at 7:03
  • Well, I admit I didn't think it through that well. The main idea of (the static) __fromType($instance) is that it could resolve in constructing an object from another instance lacking (or explicitly returning null through) a __toType($type) method e.g. $f = (FileInfo) 'path/to/file';. Concerning __toString(), I would rather see the other primitive types as well though that doesn't solve object casting and in the case that I should be careful what I wish for: I rather ask for something that rules them all. – 23JUL Dec 30 '10 at 14:32
  • I'd like to see some native way to set open_basedir in virtual hosts based on domain name automatically, without having to configure one directive per host (similar to Jason Greene patch, but native).

  • Please, application-wide globals! App global variables would be available to all php scripts, once initialized.

  • Some way to release session for other threads, without closing them:

$_SESSION['favcolor'] = 'white';
session_flush(); // session is now unblocked so other threads can use it
// huge loop ...
$_SESSION['taste'] = 'sweet'; // session blocks automatically again
  • Maybe some on-disk cache would be nice, so we can precompile php scripts manually for faster execution. Similar to memory caches, but with files on disk and manual generation (probably using some new file extension).

  • Also, something similar to <?php =$variable ?> as shortcut to <?php echo $variable; ?> would be nice (as in asp tags, but with short/asp tags disabled).


When I saw this thread I thought that it would be useful to mention some articles I ran into.

  1. Sort of Groovy Groovy’s ?. operator in PHP: http://justafewlines.com/2009/10/groovys-operator-in-php-sort-of/
  2. Improve closures: http://justafewlines.com/2009/10/whats-wrong-with-php-closures/
  • I think PHP verbosity is a feature, not a problem. It seems nice to type less characters when you type it, it's much less nice when you try to figure out someone else's code. And PHP - unlike Scala - is supposed to be a language accessible to beginners. – StasM Dec 31 '10 at 21:31

Native regexp literals, Perl-style qw{}, qq{} and q{} quotes.

The chained method call for all objects: $object{ ->method1(); ->method2(); ->getPerson()->getName(); }

The statement expression: ({echo $a; $a = $a + 1; $a})

CONSISTENT, NON-CONFIGURABLE, CANNOT BE TURNED OFF short_open_tags. If they are not configurable, PHP code will be more portable. See wha including the ERB-style tags


Being wise enough to not breaking backwards compatibilty. I've learned the existence of goto as a keyword the hard way, I was using it as an method name, so an update of my code for php 5.3 took 2 or 3 hours.

Something like roles for classes would be a good addition to the object system. Nothing complicated.

class abc { use xyz::method; use uvw::__all; }

This would pick method method from class xyz and all methods from class uvm.

Constructor call should be useable as a object right after creation.

new goodie()->youp();
  1. Let scalars be treated like objects. If I try to do $scalar->toLower(); why tell me I'm wrong? Why not just temporarily cast it to something like a "Scalar" object type and then move to "undefined method" (perhaps not do this as null)?

  2. Remove resources from userspace. PHP has objects now. Everything that's a resource now can be in a object wrapper that hides it as a private property. Functionality may need to be added for __sleep() and __wakeup(). Most resources can be easily recreated in a "similar" state. Even if they can't, the PDO object can't be serialized: I assume the same can be done with other objects.

  3. Let the actual PHP community make votes with their code: allow us to redefine existing methods, classes, and functions. Bad code will rot, just like it does in Javascript. It'll let the people using PHP figure out what they need instead of needing to guess all of the time. The functions and functionality used/overridden the most likely needs to be considered.

    This also has the side-effect of involing the PHP community with the UTF (hopefully UTF-8) issues. Instead of having a system-wide setting that turns unicode on or off, PHP developers can override the functionality they need for just their application.

  4. Make _ an implcit namespace separator. People have been using it since PHP5, let people build off their code instead of rewriting if for PHP 5.3. I don't know the complexities of it. I know there's initially some thought about code that does class names like Zend_Exception: Allow it, the developer will always have to access it as Zend_Exception or \Zend\Exception and never Exception. Treat it as a full name instead of just part of one.

  5. OOP: take some hints from Javascript/Actionscript/Python. Traits look promising, but changing type dynamically at runtime would be awesome.

  6. Properties: I see talks are in the works about properties, please implement them dynamically. PHP is supposed to be a dynamic language. We should be able to define properties (just about everything) at runtime.

  7. Treat constants as what their used for: global variables. Classes/Functions/Namespaces all fit this bill. Maybe when everyone starts realizing that they're all globals right now there will be more ideas to fix the issue of there being so many global variables/constants.

  8. JIT-compiling: Javascript can do it and be super-fast. PHP is one of the few ones behind in this one.

  9. PHP is supposed to be optimized for "Hypertext", yet there's no easy way to escape output as such. Personally, I'd redefine the 'print' to do an htmlspecialchars(). Overall, it may just need to be a printh or echoh.

  10. Simplify php.ini. php.ini is for System Administrators, not developers. Remove the incompatibilities of short tags, fix them, or remove them. Its annoying for system administrators to be able to turn features of the language on/off for the entire system. And work around them when trying to distribute software.

  11. Allow PHP developer to exist after a request cycle ends (for FastCGI and Apache). Expose this over an API. Allow the system administrator to disable or limit this. (Require the php program to return control to the dispatcher within 10 seconds or it loses its persistant status).

  12. Make PHP a general programming language. <?php tags are annoying: make it not required when you detect a !#/...

  13. Shortand for creating objects {} and arrays[], Taje a look at PiHiPi, they implement this and a lot of other simple syntactical sugars.

    14: Allow [] to access properties and functions on objects. Functions and Classes are first-class citizens now, right? Make [] the de-facto way (like javascript/actionscript) for accessing things dynamically on objects.

  14. Allow PHP code to be PHP modules. I shouldn't have to learn C just to make my library available system-wide in multiple processes. Let the PHP community figure this one out more.

  15. Instead of taking ideas from Java/C, take them more from dynamic languages like Javascript, Actionscript, and Python. More specific functionality is listed below.

  16. Fatal Errors: why are most errors still not recoverable? I love the notion of logging errors in a log file (implemented at a very high level). What I don't like is always hearing about a "white page". I do a lot of checks and declarations in my code to avoid these: but when someone passes a null instead of an object to my function, god forbid that PHP can recover from such a catastrophic without making me do an is_null() myself. Sure its an error, it just seems silly that most other languages call this a NullReferenceError/Exception that can be dealt with and presented with more than just a white screen.

    At the very least, stop adding fatal errors. I have the ability to upgrade a lot of servers running PHP 5.2, but I can't: because I don't have time to go through ~200 sites on each server to fix the old code. The less new fatal errors you add, the more likely you can get people on board with new versions of PHP.

    Remove as many fatal errors from the language as possible. PHP is supposed to be a dynamic language: why can every other language recover from most errors PHP considers fatal? Programmers can work around errors, but not if the program forcibly dies after what most languages consider a NullReferenceException.

  17. Make exceptions resumable. So we can more easily intermix exceptions and errors.

  18. (The most time-consuming and unlikely) Separate out the language-discussion, API/module discussion, and the interpreter discussion. They shouldn't be so integrated like right now. Issues with the current interpreter should be figured out last. Pypy/Parrot/JVM all support multiple languages. V8 doesn't, but its fast enough that some are working to compile other languages into JavaScript to run on V8 and take advantage of its capabilities.

    As a interpretter/runtime/vm, the development goals are a bit different than a language. With PHP, it feels as if they're one in the same. So people who try developing other interpreters are having a hard time keeping up with discussions when all of the language-design discussion is mixed in with the PHP-interpreter discussion.

    As an interpreter, I feel that the more languages the interpreter supports the better. Why can't we have a <?python or a <?javascript or a <?actionscript. I'm tired of rewriting code in another language so I may use it there. Some are already trying to do this, it'd likely rally up support from other areas of the community.

  • I want to upvote points 12 & 18 of this post, but none of the others :-). – rjmunro Jan 6 '11 at 23:33
  • @rjmunro Is there a good reason to keep Fatal Errors, asides from "hardware" problems like "Out of Memory"? – Reece45 Jan 8 '11 at 18:57
  • I'm not saying I disagree with the other points, just that they aren't original enough for me to upvote - most of the others are mentioned by other people. – rjmunro Jan 9 '11 at 0:19

include better hypertext-links support, i.e. a function/class-method that can be used to change the browser's current-uri. or to create a totally new one. using $_SERVER[ 'REQUEST_URI' ] || $_SERVER[ 'PATH_INFO' ] to understand the resource that is requested. This might make something like developing REST-apps easier. ( according rfc's UriScheme and it's default scheme implementation, maybe make it possible to implement other UriSchemes extending the UriBase)

Provide something like a UriResource class, enabling requesting small snippets of functionality in a way that could also benefit http-requests from a client.

Make a function that can be called before and after a template, enabling short-tags between those two function-calls. Between those function-calls the only variables that are made available are those passed to the first function-call( as associative array( using extract)). This might ease template-development in php itself( no-framework framework). The no-framework PHP MVC framework

All in all i think the many php frameworks out there have certain similarities which could easily be integrated into php in a common way.

but whoami :)


I like the php progress and scalability in the recent days.

The new features introduced in java have only make the things complex rather then making it simple.

request 1: db-connection-pool facility as additional library.

request 2:

I am asking for the reverse ajax or comet programming or RTMP facility as a built in library.These are already developed for .net,java, python and perl by dojo foundation

We have similar things in php but not a complete solution.

  1. Also there is support for observer pattern in SPL. but not properly documented.
  2. Xajax framework (good but it requires redesign the application)

bye for now.


I really would like to have annotations.. afaik that RFC has been dropped.


few things that would make my day

  • Sane naming conventions for built-in functions.
  • Type hints for strings and numerics
  • Return type hinting
  • E_STRICT on by default
  • Traits, mixins, & multiple inheritance
  • Everything is an object (i.e. ruby-like pureness)
  • Add :: support to namespaces
  • Better windows support
  • Testing out of the box
  • Better documentation for the underworkings of exec()
  • Redesign of php.net with live-search
  • Xdebug like functionality out of the box
  • Improvement of PEAR portability - users of ruby gems should know
  1. Immutable value objects
  2. Anonymous classes and/or classes as objects
  3. Builtin object equivalent to string data type (mentioned earlier)
  4. Annotations or Python-like decorators
  5. Singleton objects like in Scala
  6. Default errors as exceptions (mentioned earlier)
  7. UTF8 support
  8. Removal of global etc
  9. Unified access principle - one way to call object methods and manipulating properites (see Scala)
  • UTF-8 support
  • Make the language fully OO, borrowing the Ruby and Python concept that everything is an object. I kinda liked the autoboxing rfc. However it gives way too much freedom to the developers which is not that good. But with some limitations it could be a nice addition to the language evolution.

$x = array(5, 60, 50, 50); $x->map(function($i) { return $i * 2; })->push(10);

$p = "some string"; $q = $p->substring(0, 10);


In my oppinion this can be done without breaking the current global functions. However, most of them will become useless and could be deprecated over time.

  • Short notation for arrays would be nice, but it's not critical for the language.
  • 4. Make extensions consistent. Is some extensions class functions are CamelCased, while in others - under_scored. – Josh Scott Dec 29 '10 at 23:22
  • What do you mean by utf-8 support? – StasM Dec 31 '10 at 21:27

It would be nice to be able to use a class that extends iterable in a foreach loop, where you pass a reference to the loop:

foreach(&$myclass as $me) {
  echo $me;

I haven't spent much time looking into why that doesn't currently work, perhaps it's related to how iterables work, I haven't investigated much more than just noticing that it doesn't work.

  • why do you need to pass reference into the loop - what should it do? – StasM Dec 30 '10 at 9:43

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

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