rfc:structured_object_notation

PHP RFC: Structured Object Notation

Introduction

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:

<?php
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;
});
$app->run();

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.

Proposal

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:

<?php
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::foo();
    }
}
 
$a = new A();
$a->foo();
 
A::foo();
$b = new B();
$b->bar();
 
B::bar();
?>

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
Arguments:
    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");
$app->foo(1,2);
$app->bar(3,4);

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);
        $this->foo(1,2);
    }(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

To SAPIs

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

Implementation

No implementation still.

References

Links to external references, discussions or RFCs

https://docs.oracle.com/javase/tutorial/java/concepts/object.html

Rejected Features

NA.

rfc/structured_object_notation.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1