PHP RFC: Structured Object Notation

• Version: 0.0.1
• Date: 2016-07-31
• Author: Midori Kocak, mtkocak@gmail.com
• Status: Draft
• First Published at: https://wiki.php.net/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:

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

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.

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

What breaks, and what is the justification for it?

List the proposed PHP versions that the feature will be included in. Use relative versions such as “next PHP 7.x” or “next PHP 7.x.y”.

Describe the impact to CLI, Development web server, embedded PHP etc.

Will existing extensions be affected?

It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP.

Please explain how you have verified your RFC's compatibility with opcache.

Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation.

If there are any php.ini settings then list:

• hardcoded default values
• php.ini-development values
• php.ini-production values

Make sure there are no open issues when the vote starts!

List existing areas/features of PHP that will not be changed by the RFC.

This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.

This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

Include these so readers know where you are heading and can discuss the proposed voting options.

State whether this project requires a 2/3 or 50%+1 majority (see voting)

Links to any external patches and tests go here.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

Make it clear if the patch is intended to be the final patch, or is just a prototype.

After the project is implemented, this section should contain

1. the version(s) it was merged to
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

Links to external references, discussions or RFCs

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

Keep this updated with features that were discussed on the mail lists.