Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93084
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.111.102 as permitted sender)
To: Alexander Lisachenko <lisachenko.it@gmail.com>, Stanislav Malyshev
	<smalyshev@gmail.com>
References: <5723F2AE.2020806@garfieldtech.com>
 <d158ceff-b888-604c-387c-942239c0e783@zend.com>
 <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
 <CAEbg-4a3F=OA=cx74LUyNQV7gcDkUEptwBJKjhDR2_F5ybgnUQ@mail.gmail.com>
CC: Larry Garfield <larry@garfieldtech.com>, PHP internals
	<internals@lists.php.net>
Message-ID: <7f04c375-9f6f-f107-fe5a-a39c19bcd05c@zend.com>
Date: Thu, 5 May 2016 10:34:21 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CAEbg-4a3F=OA=cx74LUyNQV7gcDkUEptwBJKjhDR2_F5ybgnUQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------68452C4A337EF18E440B234E"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2016 07:34:33.7783 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1788
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: dmitry@zend.com (Dmitry Stogov)

--------------68452C4A337EF18E440B234E
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit



On 05/05/2016 10:24 AM, Alexander Lisachenko wrote:
> Hello, internals!
>
>
> 2016-05-05 9:48 GMT+03:00 Stanislav Malyshev <smalyshev@gmail.com 
> <mailto: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.
>
Something like this may be implemented, but it should be well designed 
and approved first.
I'm not sure if this functionality should be especially implemented as 
part of Reflection API (this is easily implementable in PHP itself).
But in any case, this requires the base attribute functionality proposed 
in RFC (or some other).

Thanks. Dmitry.

--------------68452C4A337EF18E440B234E--