Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
References: <5723F2AE.2020806@garfieldtech.com>
	<d158ceff-b888-604c-387c-942239c0e783@zend.com>
	<8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
Date: Thu, 5 May 2016 10:24:41 +0300
Message-ID: <CAEbg-4a3F=OA=cx74LUyNQV7gcDkUEptwBJKjhDR2_F5ybgnUQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Larry Garfield <larry@garfieldtech.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113fb5805764bd0532133c51
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--001a113fb5805764bd0532133c51
Content-Type: text/plain; charset=UTF-8

Hello, internals!


2016-05-05 9:48 GMT+03:00 Stanislav Malyshev <smalyshev@gmail.com>:

> Maybe that's what we want to have here - freedom for everybody to invent
> their own languages - but I fear the danger of fragmentation here and
> also people implementing tons of slightly different incompatible parsers
> for ASTs that are generated. We'd have Drupal attributes and Symphony
> attributes and Doctrine attributes and Zend attributes and so on, and
> each of them would have different semantics. Not sure this would be
> good. But maybe it avoids arguing about the syntax now.
>

AST for attributes is a nice thing for abstracting from the concrete
details about how attribute is handling by the concrete implementation. I
can see a lot of common with class autoloading - earlier there were a lot
of custom loaders, thanks to spl_autoload_register() that defines a stack
of callbacks responsible for loading classes by their names. And everyone
uses custom class loader, but later PSR-0 and PSR-4 were described and
adopted in composer, so now we have one general tool for that. What if we
select the same direction with the stack of callback?

How it should work: PHP engine stores all attributes in the plain AST
without any transformations. This data should be accessible via
ReflectionXXX->getAttributes(ReflectionAttribute::RETURN_AST). After that
userland library can register a hook as attribute loader: e.g
ReflectionAttribute::registerProcessor(SomeHandler::class, $isPrepend =
true) or spl_attribute_handler_register(SomeProcessor::class, $isPrepend =
true)

Each processor is a class with two methods:

interface AttributeProcessorInterface {
    public function supports(Php\Ast\Node $attributeNode) : boolean;
    /** @return mixed */
    public function process(Php\Ast\Node $attributeNode);
}

After that if we call
ReflectionXXX->getAttributes(ReflectionAttribute::RETURN_VALUE) PHP engine
will call each processor and asks it if it supports this AST node. If
processor supports this node, then engine call it's process($attributeNode)
method, returning the result as a result, otherwise looks for another
processor. If no processors can handle this AST then PHP can throw an
exception about with information about missing processors for attributes.

I think this way can give a good start point with possibility to
standardize handling of attributes in the future. From the PHP engine side,
all attributes are AST nodes that can be processed later on the userland
side.

--001a113fb5805764bd0532133c51--