Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 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

A language-integrated-query-engine would be great. Sort of like what is available in .NET called LINQ. It would help sort through massive arrays of data, and standardize database access, so that fewer SQL-injection attacks succeed.

Anything that makes parameterized queries easier gets my vote! –  Dean Harding Dec 18 '10 at 14:57
I think the standardized database access is actually a very important benefit of something like LINQ, because I think it makes unit testing with mocks of your database objects easier (since you're mocking PHP code instead of SQL queries.) –  notJim Dec 18 '10 at 19:42

PHP suits me just fine as it is for knocking up small to medium websites; I must be a bit unimaginative, the only thing I could think of as a response to this question would be something that makes it scale better for high traffic sites.

I'm thinking in terms of spawning off processes to other cores, for example updating a database in one process while creating the output page in another process. A quick google search indicates that this can be simulated, but is not supported directly in php at present.

Actually, thinking more about it, offloading database seems to be interesting scenario, so +1 on that :) –  StasM Dec 17 '10 at 21:40
@Stasm, I assume you mean that separate requests run as separate processes. I'm talking about a complex page that requires page generation and background computation. I could be wrong, but I don't think there is a way to spawn off (for example) database update operations in a separate process. The reason for doing this would be to get the page sent to the requester sooner, rather than having to wait for all the processing that isn't directly related to producing the page to complete serially. PS.. Thanks for the update! –  geekbrit Dec 17 '10 at 21:41
  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.
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() {}
if you do $foo->login(), how do you know which one of those gets called? –  StasM Dec 17 '10 at 21:46
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
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. –  notJim Dec 18 '10 at 15:50

1) please get rid of includes(). References to other files should be references, and not actually place the contents of one source code file into another. Far too many PHP programmers use includes() as a type of function call rather than a means to reference a library. This leads to all sorts of ambiguity in variable state and unstable code. Replace this with a Perl-like 'use' command.

2) please provide an out of the box method of compiling a PHP application into a single distributable bytecode file or executable. This will greatly enhance the appeal of PHP as a commercial development language. This should be a basic component of the language. Dont worry about the html files used for an application's GUI because...

3) please get rid of the ability to embed PHP tags into HTML. Or at least provide a 'no embed' mode. This is an absolute mess and encourages bad design by mixing application logic and presentation together. Developers should be using templates for display and not slapping PHP files together and hoping for the best.



ps: dont listen to what others here say, I've been nice all year

1). Includes are great. Everything has includes. 2). This is good. 3) Templating is PHP's strongest feature. Forcing you to use some other templating bullshit would be a very bad move. –  Josh K Dec 17 '10 at 22:46
I like (1) and (2), but (3) seems like a retrograde step. PHP gives you the templating power, it's up to you whether you use it wisely or not. –  geekbrit Dec 18 '10 at 19:23
3 makes no sense - embedding tags is necessary for any V in MVC frameworks. –  Alex Dec 18 '10 at 23:05
I read this answer as "Dear Santa, please make PHP not be PHP." –  Stephen Dec 21 '10 at 22:50
3 is right out, as PHP is a templating language. –  Andrew Jan 28 '11 at 14:50

I really missed that scalar types are not treated as objects, and real objects can not act like any other type or object (except for string due to __toString()).


I wouldn't mind named parameters.

getData(0, 10, filter => NULL, cache => true, removeDups => true);
// instead of:
getData(0, 10, NULL, true, true);

// or how about:
img(src => 'blah.jpg', alt => 'an albino platypus', title => 'Yowza!');

Unfortunately the PHP devs shot that idea down already.

It's the list from 2005. Many ideas were shut down and then reborn. Actually, if a good implementation comes, there's a decent chance it'd be accepted. –  StasM Dec 18 '10 at 17:21
It's my favorite python feature. Makes the code very self-documenting. –  Keyo Dec 18 '10 at 17:21
@Josh K: It's possible alright, but the 'array' call is useless garbage if you will. It only obfuscates what you are REALLY trying to do. Another option would be a shorthand syntax for arrays: make_img(['src' => 'blah.jpg', ...]); –  Erik van Brakel Dec 18 '10 at 21:52
@Erik: That's not a bad option either, I'm saying why add this clutter to a language when you can do it already with a minor array wrapper. –  Josh K Dec 18 '10 at 22:04
@Erik: More relaxed syntax for arrays (like JavaScript's [] operator) would be an appreciated feature. –  Josh K Dec 25 '10 at 20:47

Things I would like, as a former long-time PHP apologist:

  1. Shorter syntax for arrays. PHP arrays are one of the awesomest features of the language because of their flexibility, but it's a drag to write some_array_method($argity, array('key' => $value));. I believe this proposal was already eviscerated on the PHP mailing list unfortunately.
  2. finally support
  3. Attributes/annotations. These allow you to add custom behavior to a method in a way that allows code reuse. For example, in an MVC framework, one could define an AuthorizeAttribute that would indicate that a controller or action method requires the user to be authorized. The framework itself would be responsible for looking for the attributes and acting on them accordingly. I believe PHPUnit already uses a sort of attribute by putting them in docblock comments, which can be read using reflection, but putting actual functionality in docblock comments is certainly a hack.
  4. Shorter lambda syntax. Instead of having to write function($x){ return $x*2;}, maybe I could write $x => return $x*2, or something. This is again something just sort of makes it a drag to use this feature. For example $results = array_filter(array(1,2,3), function($a) { return $a % 2; }): vs $results = array_filter(array(1,2,3), $a => return $a % 2 ); The former just has so much more plumbing that's basically irrelevant to the actual work you're trying to accomplish.
  5. A built-in Decimal (fixed-point math) that supported math operations through the normal operators would be kind of nice, since we don't have operator overloading.
  6. MOAR MAGIC METHODS. Magic methods are great. I could see PHP adding operator overloading via magic methods (I know this will basically never happen.) But in general, they provide really great ways to hook into the language and do cool things.

Make PHP truly object oriented. The slap on another global function evolution of PHP needs to end.

array_merge(array_filter(array_intersect_key($arr1, $arr2), "is_int"), $arr3);

This is hard for me to read. I have to make my own mental stack and sort of compile it myself. Basically it should read in the reverse. $dog->wakeup()->bark(); is easy to read compared to bark(wakeup($dog))


You've made the step towards enabling object/method support now please use it in actual core PHP functions.

Let's rename 500 functions and change parameter order for them.

Shifting this functionality to methods would enable them to be renamed using some consistently. Would it break any backwards compatibility if strings and arrays had their own methods?

I think array not being an object type is a big mistake in PHP. Leads to all kinds of trouble. Unfortunately, it's an evolutionary thing. You can do what you want here with extension or userspace though. Would probably fit SPL well. –  StasM Dec 18 '10 at 17:24
The same argument applies to strings. I'm just referring to the lack of methods in general. Languages like Java, Python, C# etc all have much more readable code. I guess you are looking for features, but fixing what is IMO broken would be a better pay off. –  Keyo Dec 18 '10 at 17:28
No, don't be silly. It'd be dog_wake_up($dog); bark_dog($dog); –  Matchu Dec 24 '10 at 18:24
IMHO, any new string methods should expect and emit UTF-8, and throw exceptions if the input is not valid UTF-8. This would greatly reduce the need for a major reworking of unicode support. –  rjmunro Jan 6 '11 at 23:39
@luiscubal No. An extra parameter will mean that we can't add parameters later if we invent new things to add to the function. For example, if $string=>trim() only did whitespace (like before 4.1.0), then your system would say $string=>trim('ISO-8859-1') trimmed whitespace from ISO-8859-1 strings. If we then wanted to be able to trim stuff that wasn't whitespace, we'd be unable to add the parameter for that, unless we make people specify the encoding first. We should be encouraging people to believe that any text anywhere that is not UTF-8 is wrong. –  rjmunro Apr 17 '11 at 0:00

There are some fairly decent array functions in PHP, providing list processing capacity, with callbacks and create_function() providing a basic lambda calculus.

The main problem with it, is that it is far too verbose in PHP, a shorthand system would be excellent, particularly where the map/reduce commands are concerned.

More importantly, the list functions are not entirely complete:

  • there is no foldr function, array_reduce() provides foldl
  • array_map() should pass the key in the second argument, as array_walk() does
  • an array_map_keys() could be useful for key modification
  • list comprehension is very clunky, range(), array_fill() and array_fill_keys() only handle so many cases, and array_filter() is separate

I'm not aiming to make PHP in to Haskell, but PHP is often used for list type data structure manipulation and having a full set of tools in this regard would be useful.

A colleague of mine also thinks there could/should be some other additions re array related functions; at mentioned on his github account: These are are the lack of array_all() and array_any(), which check if * a condition represented by a callback holds for all or any of the elements in an array. gist.github.com/44350 –  kguest Dec 25 '10 at 23:14

I would like to see a legit method of creating/defining CONSTANT arrays. There are a few hackish ways to simulate this kind of functionality but it would be nice if it was just a straight up feature of PHP. It would be nice if you could create an array in a way that is similar to Java's "final" declaration.

I created a login system that is very quick to setup. All you have to do is change the contents of an array in a text file to specify the fields you want for user information. Using a swath of for loops it handles everything from form generation and input sensitization, to database calls but it is all dependent on this original array.

The file with the array is locked down with permissions but once the array is moving around in the ether it is mutable. Although I feel the system is pretty secure I don't like leaving anything to chance. A method to finalize arrays would be nice for a situation like this.

New Idea!!

Ohhh, I thought of something else I would really really like in php. I would like some kind of system to control php file operations and directory operations similar to the way .htaccess works.

The .phpaccess file should trigger some kind same domain/same origin policy.

For example, If I were hosting many sites with virtual hosts I could have a .phpaccess file in a directory that would tell php to check the orgin of any scripts being executed which are trying to operate on my protected directory. If the script did not come from that directory or its sub-directories then the file operations / or socket operations will be denied.

I think a system like this would make virtual hosting a much safer environment. If you could place one of these at the top of each virtual host it would lessen the chance of someone finding a way to sneak in from a neighboring virtual host.

Also if it would be good to have a method of securing it in the inverse of this manner. ie, restricting the reach of scripts in a single directory to that directory.

Its the yin and the yang ya know!

there's a proposal for getters/setters for trunk that would supercede readonly, etc. Immutable arrays though probably would be hard to do. –  StasM Dec 18 '10 at 22:45

I really wish for better unicode support out of the box. Most languages move in that direction but PHP still have strange commands littered all over.

PHP strings are just plain byte arrays. Their content is non-portable as it is dependent on the current default encoding.

The same applies to the representation built by serialize. It contains a length-prefixed byte representation of the string without actually storing any encoding information.

Most PHP (string) functions have no clue about Unicode. For a detailed list including each function’s risk level, refer to: http://www.phpwact.org/php/i18n/utf-8


BTW, the quote is incorrect. PHP strings are byte arrays, but their content is as portable as you make them and is not dependent on "default encoding" - it's just array of bytes, you want them in utf8, put utf8, want utf16 - put utf16. phpwact.org link seems to be dead. –  StasM Dec 18 '10 at 23:31
I would really hope that the intl extension would be enabled by default, so people that needed UTF-8 (doesn't everyone?) didn't have to fight their hosts to get the string functions to behave like expected. –  Emil Stenström Dec 19 '10 at 12:19

Normalize the global namespace with a well thought-out naming convention that makes sense to new-comers!

To quote our beloved Jeff Atwood: PHP sucks but it doesn't matter!

I agree in principle, but have no idea how to do it in practice :) –  StasM Dec 18 '10 at 22:47
@StasM: I imagine the first step would be to make the new versions of libraries namespaced and allow programmers (via ini settings) to disable the currently global libraries. I would think a compatibility pack would be in order for older versions, but shouldn't be very difficult to write. –  Pies Dec 20 '10 at 15:15

My two biggest wishes as a hardcore PHP programmer:

  1. Support finally. It's a big mess to fictionally get around this through flags or similar means.
  2. I would LOVE to see support on C#'s syntax for getters and setters. When you have lots of getters and setters a simple syntax such as C#'s is a great performance booster instead of doing it the Java way and writing getter and setter methods. Magic methods are awesome in cases where you want to create members dynamically (for instance, if you want to give a template renderer some variables to use), but are no good for normal properties on which you would like the IDE to autocomplete, know their types, and so on. this would help make code smaller and still as readable and easy to use.
1. unfortunately, it's hard to do, but definitely a good todo item 2. wiki.php.net/rfc/propertygetsetsyntax –  StasM Dec 18 '10 at 22:59

More dereferencing:

echo something_that_returns_array()[4];

Others have mentioned named parameters, and shorter array syntax. I wouldn't mind shorter object syntax, as well.

$a1 = array(1, 2, 3, 4);
$a2 = [1, 2, 3, 4];

$b1 = (object)array('name' => 'foo');
$b2 = {'name' => 'foo'}; // or something?
()[] syntax is already in trunk. Unfortunately, array shortcuts were rejected, but I hope for resurrection. –  StasM Dec 18 '10 at 22:44
I would love this feature. Why can we have something_that_returns_object()->4, but not with arrays? –  Bala Clark Dec 19 '10 at 8:22
Javascript like array and object notations would rock. As a front end developer that is what bothers me most in php code. –  faB Dec 23 '10 at 0:27
@DisgruntledGoat It does, see: function something_that_returns_array() { return array( 'a', 'b', 'c', 'd', 'e' ); } –  Adam Backstrom May 21 '11 at 1:55
@DisgruntledGoat: The problem with the ()-> syntax is, that it only works when an object is returned, to make matters worse, the object is even required have a property/method of the specified name, which, optimally, does what you hope it does, while accepting the parameters you've given it, and praying that it doesn't require any more... etc etc. –  phant0m Jul 23 '11 at 23:44

Bring taint support up to latest version and include it in standard builds, preferably turned on in the default config http://wiki.php.net/rfc/taint

This would prevent XSS and SQL injection attacks by making people code properly.


Oh. Type hinting for primitives. That would be nice.

Although I like PHP's KISS principle (to an extend), I strongly second that. The reason is that if you want to be really defensive, you end up with the same type checking code in each setter method. We could easily drop that if the language supported it natively. –  MicE Dec 18 '10 at 22:26
"Type hinting" was very unfortunate name, as it's not "hinting", it's strict typing. I think primitive strict typing would be out of place in dynamic language like PHP. Coercive typing (same thing that internal functions do - try strlen(123)) may be OK. –  StasM Dec 18 '10 at 22:42
+1 for this. Type hinting (or strict typing) in function declarations would be incredibly helpful and cut down on so much if(!is_int()) crap in EACH AND EVERY method. –  Phil Sturgeon Dec 21 '10 at 11:54
@StasM I disagree. It is perfectly with in the scope of a dynamic language to allow the user to choose to use the language in a statically typed way. And it would allow for much better error catching. You wouldn't have to use it if you didn't want to, but personally I'm fed up of having strings passed where I wanted an int and then having to search through code to figure out where the stupid string is getting passed in. Or else, type checking everything all the time. –  Daniel Bingham Dec 28 '10 at 17:15
@StasM There is absolutely no reason you would have to introduce fully statically typed variables. Yes, you would shift the errors around in your code. That would be the whole point. The error would occur at function call time instead of inside the function -- which leaves you with no idea where the error is actually occuring. As for type conversion errors, the error would occur -- yes at run time -- at the function call. Fix the problem by converting right there to the correct type. Much better than having a string appear in a function expecting an int and not knowing from where. –  Daniel Bingham Dec 28 '10 at 21:33

Make strings object like, with built in methods to replace the inconsistently named and parametered non-object ones. e.g.



Edit: one more thing: These methods should always expect and emit UTF-8, except for ones specifically intended to deal with encodings. If input is invalid UTF-8, an exception should be thrown, even if the output of the function wouldn't be affected by the encoding.

subject->verb(object), makes parameter order easier to remember. –  SHiNKiROU Dec 30 '10 at 4:09
So what would is_object($string) return? This would either break backwards compatibility big time, or result in the introduction of really unintuitive almost-but-not-quite-objects. –  Tgr Apr 16 '11 at 16:37

An ini directive to E_ERROR on undefined constants, rather than assume it's a string with E_NOTICE.

Class constants do that, btw. –  StasM Dec 18 '10 at 22:40
Seriously I don't understand why they make PHP assume unquoted strings. It's the stupidest thing ever. I would choose either E_ERROR or E_PARSE. –  BoltClock Dec 18 '10 at 23:02

1) Array comprehension in the style of Python list comprehension:

$newlist = array($x->something for $x in $oldlist);

//with short array syntax:
$newlist = [$x->something for $x in $oldlist];

2) Short array syntax

$newlist = [1,2,3,4,...];

3) Make empty() not consider the string '0' as true

I think for (1) something cooked from iterator & closure would be better. –  StasM Dec 18 '10 at 23:02

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 :)


Operator overloading:

$result = $MatrixA + $MatrixB * $MatrixC;
Not sure how well this would click with PHP being a dynamically-typed language. –  BoltClock Dec 18 '10 at 23:07
Maybe it should be done via magic methods, like __add($obj), __times($obj) etc. –  Pies Dec 20 '10 at 16:20

Strings should be objects

I wish I could upvote this more than once. –  EricBoersma Jun 24 '11 at 20:54

I'd love to see unification of Errors and Exceptions into a single concept (Exceptions). Its great to be able to catch exceptions and write them to a log, to find and fix bugs that way. But if there's something fundamentally wrong (read: PHP Error) in a codepath that is very rarely hit, there's no good way to funnel that info into that same database of issues.

Please, Santa, introduce a switch in php.ini that would make all errors into exceptions - ideally, exceptions I can catch in my code.

There's already support in the engine for that and many extensions use it. You can also easily do it with set_error_handler() and ErrorException. Beware of E_STRICT/E_NOTICE/E_DEPRECATED though... –  StasM Dec 18 '10 at 22:56

After working with PHP for about 13 years, and heavily with JS for about 4, there are a couple things I think PHP would do well to borrow from JS:

1) shorthand notation for Arrays and Objects. I believe this may have been discussed and shot down on Internals (so I hear – I don't like to see how the sausage is made), but I really, really find that the literal notation for arrays and objects in JS is a big productivity win.

For example:

$arr     = [1,2,3,4];
$assoc   = [foo=>'bar', baz=>'boo'];
$stdobj  = {foo->'bar', baz->'boo'};

Is (IMHO) just much easier to write and cleaner than

$arr     = array(1,2,3,4); // not too bad
$assoc   = array("foo"=>'bar', baz=>'boo'); // not too bad either
$stdobj  = new stdClass; // this gets pretty rough
$stdobj->foo = 'bar';
$stdobj->baz = 'boo';

I've heard that some concern about potential confusion was raised, but really, is this any more confusing than, say, heredoc notation? At very least, making a stdClass object in PHP is verbose enough to discourage the practice, I think.

2) Being able to redefine previously-defined functions and methods would be really useful. It would particular simplify situations extending a class and instantiating the new class is either overly complex or impractical. I do think we should avoid redefinition of core/non-userspace functions and methods, though.

In addition to those two, I think PHP must transparently support unicode. This is becoming more and more of a problem for developers, and the solutions currently offered in PHP are confusing and frequently non-performant. Making all standard string functionality unicode-friendly out of the box would be a massive win for PHP programmers.

Thanks for asking!

As for unicode: it may be hard, but it would be massively useful (surely developing PHP itself is hard, but it provides great benefits, yes?) Perhaps a solution would be to enable transparent unicode via an extension with the understood perf tradeoff, much like XHP? Thanks again. –  Funkatron Dec 18 '10 at 23:21
$object = (object)array("foo"=>'bar', baz=>'boo'); –  mercutio Dec 19 '10 at 9:55
I don't see how you can see "most of the outside world is not unicode"? Are you talking about people? Or something else? Because the vast majority of people in the world (by a huge margin) speak languages that are best represented by Unicode. –  Dean Harding Dec 19 '10 at 22:15
Definitely unicode support. Shipping any sort of globally used app is a non-starter without it. Whether the PHP devs think engineering in decent unicode support is easy or not is beside the point. People need it, and they're hacking their way around the platform's failings to do it. Delphi did it by adding another string type and making it the default, with implicit casting, and a global switch to get the old behavior back. Why can't PHP do it the same way? –  Joeri Sebrechts Dec 27 '10 at 19:40

1) I would love for newly instantiated objects to return "$this" so I can method chain, $user = new User('john')->setLastName('Doe')->save();

2) If you've ever used ruby, and most recently node, they have a great interactive shell (IRB). I would love for PHP to have one that was actually useful.

3) Traits/Mixins, but I hear those are on the way.

4) I want to second the short array $myArray = ['my', 'array'];

5) Consistent naming/order (i.e. needle haystack)

There's also a PEAR package that offers an interactive shell for coding out quick experiments in PHP - available at pear.php.net/package/PHP_Shell –  kguest Dec 25 '10 at 22:55

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.

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

1) Shorter array/object syntax, a la JavaScript (as previously mentioned)

2) Allow const variables to allow the result of a calculation like define() does.

3) Chaining directly from the constructor: new User()->name('Ryan');

4) Array dereferencing: something_that_returns_array()[4];

5) Expanded SPL support. SPL does a decent job of reimagining string and array functions (among other things) as objects. Expanding SPL could solve a lot of gripes about the language being so janky.

6) Using ArrayObject() should be as transparent as using array(). You should be able to do things like array_filter($array_object_instance) without doing array_filter($array_object_instance->getArrayCopy()). Even better, of course, would be $array_object_instance->filter().

7) Full-on Unicode would be nice.

8) Stop doing weird automatic type conversions. For example, you should not be able to echo a SimpleXMLElement object without first explicitly typecasting it as a string. Or at least, throw something when it happens (e.g., in strict mode, or whatever mode error_reporting(-1) is).

9) Support for either multiple threads, or some sort of evented/asynchronous callbacks. This matters most when trying to upload large files via cURL. Instead of old-skool threads, something like Apple's Grand Central Dispatch would be nice. Or even something JavaScript-like where you can make async requests and define callbacks.

10) Consistent naming/order (i.e. needle haystack) would be nice, but I think this could be better solved with SPL.

11) An officially supported interactive PHP shell, like IRB. Facebook has one called phpsh that was written in Python, but it lacks the polish I would like to see.

12) For the Reflection API, add support for (a) docblock comments on constants (global & class), and (b) support for parsing PHPDoc-like comments into a sensible data structure. There's a PECL package called "docblock" that attempts to do this, but it doesn't appear that the author got very far.

EDIT: 13) I would also love to see the ability to use ! and ? in function names -- like Ruby can.


Any chance of moving PHP source to github?

We only recently moved to SVN, give it some time :) But there's a github mirror: github.com/php/php-src –  StasM Dec 19 '10 at 7:54
BTW, PHP is now moved to git. –  StasM Apr 13 '12 at 19:46

Language syntax: There are some good clues in pihipi and phpreboot of what developers are interested in (though phpreboot goes too far becoming JS).

Development methodology: It would greatly enhance the lifespan of PHP.net if such surveys were actually taken into account. Do not make any more willy-nilly afternoon IRC session syntax decisions.

Individual features: Some have been mentioned before, but I'll happily burn some karma to be extra blunt here:

  • Unicode string type.
  • Bigint (see Python).
  • Runkit builtin to remove/rename/override builtin functions and classes, which aren't always that well designed.
  • Modern OOP
    • multiple inheritance (instead of complexity to support seldom edge cases with clumsy traits syntax)
    • scalars can double as objects (see Python), e.g. array() works as ArrayObject, or strings as SplString (needs usable methods, all string funcs should be available as str::toupper())
  • Deprecate the shitty shit \ namespace syntax, fix the parser, and adopt :: as alternative. You know, like a real language.
  • Any variation of LINQ (allthough I don't trust you guys do devise a sensible syntax)
  • or XML literals.
  • Get rid of php.ini runtime behaviour and semantic switches. It takes out some of the excitement, true, but would benefit developers and user base.
  • Yes, magic_quotes are not gone yet.
  • Convert Zend Engine bytecode to PBC

Albeit, if this isn't obvious, I'd happily fund anyone else to do the latter, and kill off php.net as main implementation. :P
Oh, just noticed, it's community wiki. So there's a chance you're not actually here for the karma, but genuine interest. If so, look into the <b> issue </b> which seriously hurts the language (directoritis).

I hate \ namespace syntax, but it's a long and sad story why it became so and it probably not going to change... Probably if I could change just one thing in PHP that would be my primary candidate. But it is what it is. –  StasM Dec 19 '10 at 9:46
+ 1000000 for multiple inheritance. –  ts01 Dec 25 '10 at 1:25

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