PHP RFC: Structured Object Notation


Object Oriented Programming is a key feature to write structured programs in PHP. However, even though we have classes included in our program, the only way to create an object from a class, is to instantiate it in unstructured code. Consider this piece of code:

use \Psr\Http\Message\ServerRequestInterface as Request;
use \Psr\Http\Message\ResponseInterface as Response;
require '../vendor/autoload.php';
$app = new \Slim\App;
$app->get('/hello/{name}', function (Request $request, Response $response) {
    $name = $request->getAttribute('name');
    $response->getBody()->write("Hello, $name");
    return $response;

This causes loss of readability and benefits of oop in most of the programs. Most of the programs we write, end up to have some piece of spaghetti code somewhere. To prevent this, one should write a god object and run once but classes are not and should not be code blocks wrapped around “class” keyword. Here in this RFC, I propose a structured way to instantiate objects in a PHP script in a structured way.


According to most definitions an object is defined as: “Real-world objects share two characteristics: They all have state and behavior.” Currently to interact with an object, one should instantiate the object and send messages manually within an unstructured code blocks.

According to PHP manual a class is defined like this:

class A
    function foo()
        if (isset($this)) {
            echo '$this is defined (';
            echo get_class($this);
            echo ")\n";
        } else {
            echo "\$this is not defined.\n";
class B
    function bar()
$a = new A();
$b = new B();

The part after class definitions is an unstructured program block where we lose readability, reusability, mantainability and all the other benefits of oop. Most of cli apps we use are showing what are avaliable commands and subcommands recursively:

$ composer
Avaliable Commands:
    about - ...
    archive - ...
    browse - ...

$ composer browse -h
    packages - ...

Inspired by this, an object we create should also orient us where to go after each command. I will explain this later.

Let's have one class called B, similar to above example.

class B{
    // No way to define order of methods
    public function __construct($world = "world"){
        echo "Hello ". $world."\n";
        echo "You can foo and you can bar\n";
    public function foo($x, $y){
        echo "\nYou did foo: x is ".$x." and y is ".$y."\n";
        echo "Now you can bar\n";
    public function bar($z, $t){
        echo "\nYou did bar: z is ".$z." and t is ".$t."\n";
        echo "You can bar again or end the program\n";
    public function __destruct(){
        echo "\nGood bye\n";
// Here comes the spaghetti
$app = new B("midori");

Instead of instantiating objects on the fly, here I propose a structured definition of an object using this syntax:

object $app instanceof B{
    $world = "midori";
    // allowed methods comes after method definition
    // in the beginning state allowed methods are foo and bar
    public function __construct($world){
        // if method body is implemented,
        // parent class method run automatically
        // object method runs after.
        // This block runs $app = new B($world);
    }(foo, bar);
    // The only allowed method is bar in this state
    public function foo(1,2)(bar);
    // if allowed methods are empty or not defined
    // object is destructed
    public function bar(3,4){

An object can be instance of a class, if it's not defined, is instance of an anonymous class.

Backward Incompatible Changes

Is a new feature. Mostly a syntactic sugar thanks to anonymous classes. All of the suggested syntax can be written using PHP 7.1

Proposed PHP Version(s)

PHP 7.2

RFC Impact


Better objects with states and defines allowed method order.

Future Scope

Allowed methods can have typed parameters. Ide's can use the object notation for autocompletion. Also an object can tell allowed methods using magic method like __help() when $app->help() is called.

Proposed Voting Choices

As this is a language change, a 2/3 majority is required. A straight Yes/No vote is being held.State


No implementation still.


Links to external references, discussions or RFCs


Rejected Features


rfc/structured_object_notation.txt · Last modified: 2017/09/22 13:28 (external edit)