Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92713
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.145 as permitted sender)
To: <internals@lists.php.net>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <571B94C1.1070307@fleshgrinder.com>
Message-ID: <571DD5DF.9090906@zend.com>
Date: Mon, 25 Apr 2016 11:31:27 +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: <571B94C1.1070307@fleshgrinder.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 08:31:40.5099 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1783
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/23/2016 06:29 PM, Fleshgrinder wrote:
> +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 would need a co-author :)

>
> 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.

Different languages names this differently.
I may add an additional voting question - "annotation vs attributes?".

>
> 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.
completely disagree.
Each value in multi-value attribute may have its own meaning. e.g. 
<<if(Condition,OnTrue,OnFalse)>>

>
> 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;
>
> }
>
> ?>
You should try to implement this syntax to understand the problem.
It leads to parse conflicts.

> 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.

This RFC is not going to propose coding standards.
>
> 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 {}
>
> ?>
>
Agree. Namespaces looks better than "__" prefixes.

Thanks. Dmitry.