Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93089
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
To: internals@lists.php.net
References: <5723F2AE.2020806@garfieldtech.com>
 <d158ceff-b888-604c-387c-942239c0e783@zend.com>
 <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
 <a9ba942f-309c-e96a-86dc-595b66e4d88d@zend.com>
Message-ID: <572B5781.4000403@garfieldtech.com>
Date: Thu, 5 May 2016 09:24:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <a9ba942f-309c-e96a-86dc-595b66e4d88d@zend.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: larry@garfieldtech.com (Larry Garfield)

On 05/05/2016 02:07 AM, Dmitry Stogov wrote:
>
>>
>> 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.
> Today, we have the same with doc-comments.
> Attributes eliminate the need for separate parser and perform syntax 
> validation at compile time.
> They also provide flexible syntax to support all existing annotation 
> systems, but they can't solve semantic problems, because they are just 
> meta-data.

This, I think, is the key point of disagreement.

The proposal does not, actually, provide enough functionality to be 
useful. It's a first step, but it doesn't go far enough to actually 
address the problem space.  Because while it may provide rudimentary 
syntax validation (basically, is it a legal PHP string) it doesn't 
provide any semantic validation (it is a meaningful PHP string if 
interpreted the right way), because it doesn't define "right way".

As Rowan noted, there are lots of technically-legal PHP strings that an 
AST would be totally fine with that are still completely different and 
incompatible as far as actually using them.  To enhance his examples a bit:

<<Push($foo >> Translator)>>

<<Pipe($foo|lower|escape)>>

<<Query($foo ?? '//item[id=42]')>>

I could easily see, for instance, Doctrine annotations building the 
first, PHPUnit the second, and Zend the 3rd.  Those would all be 
legal-ish, but semantically very different.  And there's also then no 
guarantee that $foo >> Translator actually means a bit-shift (I don't 
even know what a bitshift in that case would mean), it could mean 
anything that Doctrine decided to mutate it into.  Does the second 
example actually mean to pipe values, or could it also be parsed into 
something else?  Are lower and escape function names, or magic values 
that my add-on parser knows?

At that point, the only value-add over the status quo (hack the 
docblock) is a common lexer.  But since the semantics are not guaranteed 
on top of that, it's really not that useful.

I'm not fully convinced that all the way to Doctrine classes is the 
right alternative.  It may be, it may not be, I'm not sure yet.  But as 
someone who would be using this system in user-space, I am very 
convinced that the current proposal simply doesn't go far enough to be 
useful to me.

--Larry Garfield