Hello,
Apart from the major support for Unicode that we all would like to see, I would like to see support for Namespaces being a priority, but in regards to type hints I too would like to see that we could use the package structure as type hints as well 
Another feature I would like to see would be inner classes. There are a few other things Iād like to see but first, whatās on your wish list?
The Doctorā¦
Anonymous code blocks. [fphp]create_function[/fphp] gives me a headache.
ICC
Intelligent Code Creation
i type
āmake a 3 field form for name , email address and password and make sure all three field are filled in for it to be submitted then add the 3 details into the database and email the address with confirmationā
and it spits out the necassary code the other end.
may take a little working out but im sure you code gods could do it
Not only that, but make them closures as well.
Support for properties, ala how asp.net has adopted that standard
Support for overloading.
Iāll be another vote for namespaces and also type hints for return values.
Pie in the sky, but a persistent data layer would be nice.
overloading please
namespaces would be nice
also maybe an option to compile to executable on linux (i dont care about windows),
php5.2 its fast already with APC but it still common sense tells me a binary will be much faster, also its handy in asp.net being able to just destribute a dll without sharing the code
also asp.net style widgets. for example i dont wish to spend all day messing around with javascript when lest say i want a calendar control! in asp.net u just drag it and it works no mucking around with 3rd party libraries
improving parser to allow expressions wherever a variable can be used: foo(), new (foo()) etc.
cleanup of standard library by creating new sets of string, array and file functions with consistent naming and arguments order, collating similar functions using optional flag params i.e. a_sort($ary, SORT_KEYS | SORT_DESC) etc
regexp literals
perl || semantics
goto
compiler, ability to mix bytecode with php: if(xyz) asm { 234098adefā¦ }
deprecating errors in favor of exceptions
Lexical scope for code blocks would be really nice, but that is a major change to the language, so I donāt think itāll happen.
+1 for that.
And allow any callback to be called as a function. Eg. :
$fn = Array($this, 'foo');
$fn();
Hiā¦
My preferences in order for PHP6ā¦
Anything else would just delay adoption and increase incompatibility.
For PHP7 I would like in orderā¦
yours, Marcus
Namespaces Namespaces Namespaces.
Iām gutted that the last I read on the matter was an argument on the dev mailing list about them being not needed in PHP and then progressing to āwell maybe the best we can do is allow ā:::ā to be used as a namespace separatorā which was essentially allowing class names to include those characters. They said theyād not be adding any āimportā feature to bounce between namespaces because it would slow PHP down too much and PHP was never written in a way which can be easily adapted to support it.
Iāll have to find the conversation and link to itā¦ not seen any progress since then 
Yeah, and anonymous functions.
Whatās with this too?
function global_one()
{
function closed_one() {}
function closed_two() {}
}
function global_two()
{
function closed_one() {} //Fatal error: Function closed_one previously declared
}
I donāt know if this is still valid (itās over 1 year old), however, hereās a link sent to me by a colleague of mine last year.
Iāve come up with a whole load of ideas over the months, Iām sure many of you will have reasons I havenāt thought of why they might be bad:
[list][]Unicode
[]Namespaces ( using :: )
[]Type hinted return types (only on interfaces for now)
[]Namespace visibility?
[]Class visibility
[]Proper getter/setter methods ala C# et al, maybe something like this:
public $someProp {
get {
}
set ($value) {
}
}
[]Closures
[]Deprecate, where possible, badly named functions such as call_user_func_array(), keep them on as aliases but come up with better standardized names. is_string() should be isString() for a start; inline with isSet().
[]Built in support for improving code testability? Mocks as part of SPL perhaps.
[]Completely remove @
[*]Parametrized cloning
$a = new SomeClass();
$b = clone $a('Foo', 'Bar');
[]const keyword work in any scope and deprecate define()
[]isset augmented to replace defined()
[]method and function overloading
[]āobjectā type hint - manual claims it exist; it donāt 
[]Late binding statics
[]Might be nice to disallow declaration of non-uppercase constants
[*]augment list() to get from keys
function returnsAssoc()
{
return array('foo' => 1, 'bar' => 2);
}
list('foo' => $gir, 'bar' => $zim) = returnsAssoc();
$gir; // 1
$bar; // 2
[*]Type hinting arrays of things
public function someMethod(stdClass array $param) {
// $param must be an array of stdClasses
}
[]New decorates keyword, dynamically add behaviour to an object with another class using late binding.
[]static variables inside methods arenāt static to the class as well
[*]Pipe dream: Remove dollar syntax for everything dynamic variables/constants. Use {} in heredoc and double-quoted strings. e.g.
foo = 1;
const BAR = 2;
echo "foo has value of {foo} and BAR has value of {BAR}";
zim = 'foo';
echo $zim; // 1
class SomeClass
{
static public foo = 1;
public gir = 3;
const BAR = 2;
}
SomeClass::foo; // 1
SomeClass::$zim; // 1
SomeClass::BAR; // 2
dynamicConst = 'BAR';
SomeClass::$dynamicConst; // 2
SomeClass::gir; // illegal non-static
inst = new SomeClass();
inst->gir; // 3
zim = 'gir';
inst->$zim; // 3
inst->{$zim}; // 3
inst->{'gir'}; // 3
{'zi' . 'm'}; // gir
inst->BAR; // illegal static
[/list]
Dump public/private/protected. Keep hints but make them trigger E_STRICT errors: āare you sure you really need to do this?ā Iām tempted to say dump exceptions too but perhaps I just havenāt learned how to use them properly. At the least allow $this to be thrown - or indeed any other object you like.
You can throw other objects 
I donāt think visibility should be removedā¦ perhaps made optional, but not removed. You get PHP4 behaviour by simply using āpublicā anyway. Iād actually like class visibility like in Java, but for that to have any meaning, you need namespaces first
throw new StdClass();
Fatal error: Exceptions must be valid objects derived from the Exception base class in C:\\apache\\htdocs\\foo.php
What version of PHP are you using?
No: make everything private, which means that no object but the one it belongs to may access it (and it has no effect on inheritance; every property and method is always inherited). Methods only may be designated public, which means that they may be accessed by any object. Thatās it!
I posted about three items on my blog before seeing this post: late static binding, declared accessor methods, and closures.
Inner Classes? Not necessary with anonymous functions or closures.
How about anonymous objects? Think PHON as in JSON.
PHPās builtin arrays are hashmaps already - so no need for that, although a prettier syntax for literal arrays would be nice. It would be nice though if arrays could be treated transparently as objects without explicit typecasting, a la SPL ArrayObject. Eg. making the following syntax valid:
$a = Array('foo' => "bar");
echo $a->foo; // yields bar
And in that case, perhaps object properties should be available with array syntax as well:
$o = new StdClass();
$o->foo = "bar";
echo $o['foo']; // yields bar
My point is not to represent the JS data types in PHP, but to have a literal notation for each of the PHP data types, including object. (see __set_state)