What features do you want to see in PHP6

[Dr Livingston]

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

[kyberfabrikken]

Anonymous code blocks. create_function gives me a headache.

[turbosatan]

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

[Ezku]

Anonymous code blocks. create_function gives me a headache.

Not only that, but make them closures as well.

[rvdavid]

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.

[mihd]

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

[stereofrog]

improving parser to allow expressions wherever a variable can be used: foo()[x], 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

[kyberfabrikken]

Not only that, but make them closures as well.

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.

improving parser to allow expressions wherever a variable can be used: foo()[x], new (foo()) etc.

+1 for that.

And allow any callback to be called as a function. Eg. :

$fn = Array($this, 'foo');
$fn(); 

[lastcraft]

Hi...

My preferences in order for PHP6...

* Unicode
* That's it

Anything else would just delay adoption and increase incompatibility.

For PHP7 I would like in order...
* Namespaces so that foreign code can be imported without clashing.
* Dumping the SPL and it's bloat in favour of operator methods.
* Making Array a class.
* Namespaces
* Removing gotchas, such as givesArray()[23], (new Thing())->do()
* Removal of dead features and libraries
* Namespaces
* Documenting the C interface and PECL
* Decent lambda function syntax without all that quoting or heredoc stuff (that would deal with blocks and inner classes in a reasonably PHP way).
* Did I mention namespaces?

yours, Marcus

[Chris Corbyn]

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

[Chris Corbyn]

* Decent lambda function syntax without all that quoting or heredoc stuff (that would deal with blocks and inner classes in a reasonably PHP way).

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
} 

[rvdavid]

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.

http://www.corephp.co.uk/archives/19...for-PHP-6.html

[irkengir]

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:

• 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 :P
• 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 

[McGruff]

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.

[Chris Corbyn]

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

[kyberfabrikken]

You can throw other objects

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?

[BerislavLopac]

Dump public/private/protected.

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!

[Selkirk]

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.

[kyberfabrikken]

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 

[Selkirk]

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)

[Chris Corbyn]

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?

Ah no sorry I misunderstood. I thought McG was referring to throwing subclasses like you can in other languages. Well it's fairly obvious the class needs to be derived from Exception otherwise it could have the wrong interface.

[irkengir]

kyberfabrikken, you do know you can array cast a stdClass and object cast an array?

[kyberfabrikken]

kyberfabrikken, you do know you can array cast a stdClass and object cast an array?

Yeah, but that'll create a new object.

[BerislavLopac]

Well it's fairly obvious the class needs to be derived from Exception otherwise it could have the wrong interface.

Then Exception should be an interface, and not a class. They shouldn't have blindly copied Java, which has Exception class simply because it was introduced before interfaces.

[irkengir]

Then Exception should be an interface, and not a class. They shouldn't have blindly copied Java, which has Exception class simply because it was introduced before interfaces.

Errr... then you would have to implement an exception (quite a few lines) before you could throw one.