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.
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.
--
Midori Koçak
Computer Scientist & Engineer
http://www.mynameismidori.com <http://www.mtkocak.com/>
“*The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science.*” Albert Einstein
