Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.111.139 as permitted sender)
To: Thomas Bley <mails@thomasbley.de>, <internals@lists.php.net>
References: <20160423230908.BD6F21A800F6@dd1730.kasserver.com>
Message-ID: <571DDE2B.6080903@zend.com>
Date: Mon, 25 Apr 2016 12:06:51 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <20160423230908.BD6F21A800F6@dd1730.kasserver.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 09:07:10.3046 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1781
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/24/2016 02:09 AM, Thomas Bley wrote:
> The <<>> syntax comes with the problem that previous versions cannot ignore it on parsing.
> So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then they write new frameworks for 7.1 which cannot be parsed with 7.0 and 5.x and so on.
> For companies staying on Linux distributions with long term support on 7.0, this is rather a nightmare for both users and framework maintainers.
> When choosing <<>> or any other non-backward compatible syntax for 7.1, there should be a patch for 7.0 to ignore the new syntax without parse errors.
Good point, but any syntax proposed for native attributes would break 
forward-compatibility as well.
The only choice to stay with doc-comments and do all the work at user level.

Thanks. Dmitry.

>
> Regards
> Thomas
>
> Fleshgrinder wrote on 23.04.2016 17:29:
>
>> +1 for the basic idea, however, I have various remarks.
>>
>> The RFC text is hard to read and contains many grammatical mistakes. How
>> could one help you here?
>>
>> I think that the Hack name attributes is unintelligible and annotations
>> would be much clearer to any audience. Simply because the name is very
>> well known.
>>
>> I do not see the need for multi-annotation nor multi-value support. It
>> just creates multiple ways to achieve the exact same thing for no good
>> reason.
>>
>> I do not like the <<>> syntax. It requires many key strokes, is hard to
>> read, and looks ugly. Why not simply @ and be done with it. I am not so
>> sure about the bracket requirement, is it somehow required for the
>> parsing? Otherwise I would leave it off. I guess it might be hard to
>> find the end of an annotation but have you considered to use the
>> semicolon for that? Would align nicely with existing PHP syntax. The
>> following would be the ABNF for my proposal:
>>
>> ANNOTATION    = "@" NAME [ " " VALUE ]
>> NAME          = STRING
>> VALUE         = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
>> QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
>> EXPRESSION    = PHP-CODE ";"
>>
>> A semicolon would only be required if it is not a single quoted string
>> (see following example) or constant. A question that I see unanswered is
>> how embedding of variables in quoted strings should be dealt with. I see
>> no need for this but people might assume it is supported because PHP
>> supports it everywhere else.
>>
>> <?php
>>
>> $name = "Richard Fussenegger";
>> $email = "php@fleshgrinder.com";
>>
>> @author "{$name} <{$email}>"
>> class A {}
>>
>> <<author("{$name} <{$email}>")>>
>> class B {}
>>
>> ?>
>>
>> Requiring PHP code to be terminated with a semicolon should also ensure
>> that people do not start to write fully-fledged programs in annotations.
>> Since that is not what they are intended for. An alternative approach I
>> see here would be to go for the brackets but then again only for PHP code:
>>
>> EXPRESSION = "(" PHP-CODE ")"
>>
>> Then again, it looks similar to a function call and this is imho not
>> good. Unless of course new annotations can be defined as special
>> functions directly in userland, e.g. with an `annotation function`
>> and/or `annotation class`. However, this would require more thought.
>>
>> Another question that is unanswered for me is: how to go about adding
>> annotations to a complete file as is currently possible with PhpDoc and
>> its file-level doc block:
>>
>> <?php
>> @author 'Richard Fussenegger <php@fleshgrinder.com>'
>> @copyright '2016 Richard Fussenegger'
>> @license 'MIT'
>>
>> declare(strict_types=1);
>>
>> namespace Fleshgrinder\PhpInternals;
>>
>> @description 'True annotation support could be a very good thing.'
>> @invariant $this->balance >= self::MIN_BALANCE;
>> class Account {
>>
>>   private const int MIN_BALANCE = 0;
>>
>>   private int $balance;
>>
>>   private Person $owner;
>>
>>   @require $sum >= 0;
>>   @ensure $this->balance === (old::$balance + $sum);
>>   public function deposit(int $sum): void {
>>     $this->balance += $sum;
>>   }
>>
>>   @require $sum >= 0;
>>   @require $sum <= $this->balance - self::MIN_BALANCE;
>>   @ensure $this->balance === (old::$balance - $sum);
>>   public function withdraw(int $sum): void {
>>     $this->balance -= $sum;
>>   }
>>
>>   @deprecated 'for various reasons'
>>   public function setOwner(Person $wner): void {
>>     $this->owner = $owner;
>>   }
>>
>> }
>>
>> @inheritDoc
>> class OverdraftAccount extends Account {
>>
>>   private const int MIN_BALANCE = -1000;
>>
>> }
>>
>> ?>
>>
>> We also need to make sure to add something regarding coding standards
>> for annotation names. I would propose to go for camelCase (same as for
>> method names) since this is what PhpDoc used to use for many years now.
>>
>> We also need to define how people can avoid to collide with internal
>> annotations. The typical double-underscore prefix approach that we have
>> for magic methods creates a lot of visual clutter and looks weird if
>> spread among all kinds of places. A namespace approach as we have it
>> already for userland code could help here.
>>
>> <?php
>>
>> use Doctrine\ORM;
>>
>> @ORM::entity
>> @ORM::table [
>>   'name' => 'user',
>>   'unique_constraints' => [
>>     'name' => 'user_unique',
>>     'columns' => [ 'username' ],
>>   ],
>>   'indexes' => [
>>     'name' => 'user_idx',
>>     'clumns' => [ 'email' ],
>>   ],
>>   'schema' => 'schema_name',
>> ];
>> class User {}
>>
>> ?>
>>
>> -- 
>> Richard "Fleshgrinder" Fussenegger
>>
>>