Php 5.6 Wishlist

[Hall of Famer]

Well PHP 5.5 Alpha is already released, and the new features for PHP 5.5 is pretty much set in stone and not subject to major changes anymore. Tbh it does not seem to be as much of an upgrade over PHP 5.4 compared to what an impact PHP 5.3 and 5.4 have been over older versions. But this is comprehensible considering it has not even been a year since PHP 5.4.0 came out, PHP dev team probably is trying to make more frequent releases but less new additions each time.

 

So its about time to take a step further and look at what PHP 5.6 can implement. I am bringing up a wishlist here, and I will be realistic this time. PHP sure is better off going pure OO like C# and Ruby, but I personally do not see it happening at least until PHP 6, the next major release. The fact that PHP has to compensate for a good number of newbie programmers makes it even harder goal to achieve. Still, for minor releases and maintenance releases they can at least add more OO functionalities that are missing from the current PHP core, lets see what are possible candidates to be added to PHP 5.6:

 

 

1. C# Property Accessor Syntax:

Well this has actually been proposed a while ago, many people were eager to see it implemented into PHP 5.5 but it never did. Its kinda pity, but for now we have to live with what we have. For PHP 5.6 though, I'm really looking forward to seeing this new feature being part of PHP core. The proposal on PHP RFC can be found here:

https://wiki.php.net...-as-implemented

 

There aint much to explain at this point, I like most of the recommendations made in that page. It not only simplifies the creation of getter and setter methods, but also provides a clean and flexible way of accessing properties. The final property and final property methods proposal is pretty neat too, its usefulness will come in handy.

 

 

2. Inner Class/Interface and Annoymous Class:

This may sound a bit ambitious for PHP 5.6, while I do believe there is a chance it will happen. Inner classes are rather useful in composite pattern design, it works best for a clean one to one composite relationship such as a user and a userprofile. Anonymous classes can help too, they can achieve the same effect as inner class and some prefer this style of programming. It should also be possible to define inner interfaces, which can be implemented by inner classes. It may even be a good idea to have inner trait inside an outer trait, perhaps thats already way too complicated? An example is shown below:

class User{
public $uid;
public $username;
private $password;
private $email;
interface UserInterface{
 // declaration of public methods inside.
}

class UserProfile implements UserInterface{
 // codes for user profile inside.
 }

 class UserLog implements UserInterface{
 // codes for user log inside.
 }
}

 

Oh yeah, I just realized this has not even been posted on PHP RFC at this point, which does not make any sense. Perhaps it is a difficult feature to implement? Hopefully someday it will become possible.

 

 

3. Revision of property/method/class visibility system:

Umm at this point PHP has public, private and protected visibility for properties and methods, just like what it used to be since PHP 5.0. With namespace emerging in PHP 5.3 however, the system may need to be modified slightly. At this point there is no difference between the keyword 'var' and 'public', although the former may as well become deprecated in future. Instead of having 'var' as obsolete, it can prove to be actually useful.

 

In Java the visibility public means the property/method/class can be accessed anywhere in the program, while without the public keyword it can only be used by classes in the same package. PHP sure can borrow this idea. I mean, the keyword 'var' may as well become property accessible by classes in the same namespace. Similarly for methods, if a method is not declared to be public, private or protected, it can only be used by classes in their very namespace. A public property/method, on the other hand, is globally accessible. An example of this revision is shown below:

 

namespace N1{
class C1{
 public $p1 = "public property";
 var $p2 = "namespace restricted property";
 public function m1(){
	 return "This is a method accessible globally";
 }
 function m2(){
	 return "This is a method only accessible in the namespace N1";
 }
}
}
namespace N2{
$class = new \N1\C1;
echo $class->p1;
echo $class->m1();
// This will work, and return the appropriate result.
echo $class->p2;
echo $class->m2();
// Fatal error: Cannot access nonpublic property/method p2, m2 in a different namespace!
}

 

How does that look? Well PHP may as well consider adding support for class visibility when Inner class/interface becomes available, this way you can declare an inner class/interface as private or protected. Right now a class can only be declared abstract or final, not even static. Perhaps its about time for PHP to make a push?

 

 

4. Improvement in PHP Namespace:

In my earlier thread about PHP namespacing missing an import feature, I brought up the idea that it should be allowed for client coders to import an entire subnamespace and refer to the classes inside this subnamespace by their short-name only. It becomes quite controversial, some argue it is not a good practice. I can say Static Properties/Methods aint good practices either, nor is with 'goto' statement added in PHP 5.3, and PHP implemented them anyway. The point is to give programmers another choice they can make flexibly, not mentioning how hard it is to actually prove a feature is a mis-feature until it has been used and examined in multiple applications for years.

 

Consider the situation in which you do not have 5+ layers of subnamespaces, this will simplify coding quite a bit. Here's an example:

 

namespace N1{
class C1{}
class C2{}
class C3{}
}
namespace N2{
use \N1;
$class1 = new C1;
$class2 = new C2;
$class3 = new C3;
}

 

On the other hand, I feel that its a good time for PHP to begin reorganizing their built-in libraries into appropraite namespaces rather than in a global namespace as they are today. The SPL library for instance, may as well become an SPL namespace so that you instantiate classes of ArrayObject and SPLFileInfo as SPL\ArrayObject and SPL\FileInfo. Functions can be grouped into different namespaces too, although as an OOP programmer I do not even think its necessary to have functions not in class scope at all. Its up for them to decide anyway.

 

 

5. Enum language structure:

Another feature already proposed in PHP RFC, which makes me feel optimistic that it will be available in not so distant future(maybe a year or two, hopefully not too long). Enum can help with PHP programming just like it has been in many other programming languages, its usefulness needs no more justification. The RFC post can be found below, looks like someone was able to implement it a while ago but it never actually went into voting phase. Kinda strange if you ask me, perhaps demand for it aint that high. Still, it can be a valuable addition to PHP 5.6, and definitely not as overwhelming as inner/anonymous classes:

https://wiki.php.net/rfc/enum

 

 

So what do you think?

Edited December 14, 2012 by Hall of Famer

[Adam]

You seem to be forgetting backwards compatibility! I don't really see the need for #2 - why would you need to define a class or interface within a class? Doesn't that break single responsibility? I'm not keen on the sytnax proposed for #5, doesn't seem to add anything other than changing "const" for "enum" and wrapping them within curly braces. Out of the two, I prefer the current way. What would be better IMO, would be to name the enum so you can group constants, and have some way of accessing them and being able to check if a given variable exists within the group. Perhaps something more like:

 

class Foo
{
    enum BAR = {
        BAZ = 1,
        QUX = 2
    };
}

// Either
Foo::BAR->BAZ // 1

// Or
Foo::BAR_BAZ // 1

// Then
Foo::BAR // [1, 2]

[RobertP]

i am up for the 'optional' type safety, as that could stand against most attacks right there.

[NomadicJosh]

The only one that I think would be an interesting implementation to play with is number 1. I really don't see an overwhelming need for the others or what great benefit it will add.

[KevinM1]

Properties are the big one for me. I don't understand why it hasn't been implemented yet.

[requinix]

Not a fan of undeprecating and repurposing var. I like the idea of namespace-level accessibility but I'd rather see a new keyword for it, like "internal". There's also the question of whether sub- or parent namespaces have access, and subclasses in a different namespace (as they typically are).

 

#1. Would be nice

#2. Don't care for

#4. Never needed direct access to all the classes in a namespace - always dealt with one or two classes or used fully-qualified names.

#5. If that's what it took for IDE support, okay.

[Hall of Famer]

I personally do believe PHP needs to add support for wildcard import of an entire subnamespace. Again like I pointed out before, it is a choice given to developers who want to use it. Sure there are people who contend that its not a good practice, but Id say its a matter of choice and opinion. Without wildcard import there are times I have to write 10+ or even 15+ use statement in a script file. Not sure if it does increase server load, hopefully not since it seems that I have to live with this for a few months or even years.

[Eric_WVGG]

I’m working on several projects with RESTful APIs (usually with Angular.js for the front end), and I’m a bit dismayed at the current state of support for REST principles in PHP.

 

It seems like it’s long past time where PUT and DELETE variables are considered "first-class citizens" in PHP, on level with $_GET and $_POST. The hoops that I need to jump through to get this input recognized are ridiculous. 

 

[Hall of Famer]

Well actually I hope all superglobals get erased in the next version, and instead make them collection type objects. Globals are one of the worst practice not only with OOP, but also in all programming paradigms, its unusual how PHP has this many superglobals. As far as I know, PHP has a HTTP extension, which has classes like HTTPRequest and HTTPResponse, just bundle this extension to PHP's core and bingo, you get a very good way of using Request and Response objects/classes rather than superglobals that are detrimental to quality programming.

[trq]

 

 

its unusual how PHP has this many superglobals

 

No its not. Many languages do.

[Hall of Famer]

No its not. Many languages do.

 

Maybe, but it does not contradict with the point that superglobals are bad and should be erased. Just bundle HTTP extension with PHP core already, it can repleace most of the superglobals.