Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78733
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)
Message-ID: <545A55E7.7050909@garfieldtech.com>
Date: Wed, 05 Nov 2014 10:52:55 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CALW=WECCELQOZpqB3foM6T+Qz+0v3hWT-mdTgCmGApEG4vxNcg@mail.gmail.com>
	<5457AF2F.90808@php.net>	<5457BDB7.8070701@garfieldtech.com>
	<CAFMT4NrgLzzpMt5Vm_Q84hXJ65U2jjqtLFm=ALYqwtiyxp0LjA@mail.gmail.com>
	<CAEZPtU4urLHc9FM0GohQJwkZD-TYKTVuPXcUMXsG5cAScHz3mw@mail.gmail.com>
	<54589A8D.3020607@sugarcrm.com>
	<CAEZPtU5qfcjCrcWRKW+ETF4uBp46rwVbv9nCdJoSUF+M+wKQdA@mail.gmail.com>
	<CAEPJdumXG9TC7xG8-YmGbQiwPMzwYvE_jXWvOQuNmz+U_=+ZaQ@mail.gmail.com>
	<1C3F4FA3-ABD5-4F6F-A898-F63AC1C723D5@ajf.me>
	<54591A76.8070302@sugarcrm.com>
	<967E30E5-71CB-40F8-9AE2-733D327DE197@ajf.me>
	<CAFp73XtxhW6t0k5TMa5n1ErC_7vur55Sa9oLtUM1P+X1Wugemg@mail.gmail.com>
	<545945A5.2090204@sugarcrm.com>
	<C12D441D-81CB-4270-8CE3-5A8BF2B27238@ajf.me>
	<CAFp73Xu++tT7fXE878i8CsibwNtiVJFcHQtzXi-iZA6=FXqeFA@mail.gmail.com>
	<CAFp73XuSaj4s3aqTfoOMCM6mAUM0BBncbRTyMW6uaMRgHhTphQ@mail.gmail.com>
	<CADyq6sLcYXxpyDzxrLVxS+5wgYYKh_TewgEcEAvg63p7LaNZqQ@mail.gmail.com>
 <CAEbg-4bjQ-_WYbW-53G3RYcoC0LiG=wFLkBXjio26NsF3fR+XQ@mail.gmail.com>
In-Reply-To: <CAEbg-4bjQ-_WYbW-53G3RYcoC0LiG=wFLkBXjio26NsF3fR+XQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Annotation PHP 7
From: larry@garfieldtech.com (Larry Garfield)

On 11/5/14, 9:15 AM, Alexander Lisachenko wrote:
> 2014-11-05 17:02 GMT+03:00 Marco Pivetta <ocramius@gmail.com>:
>
>> For example, this alternative approach perfectly fits the current
>> doctrine/annotations use-case:
>>
>> use Doctrine\ORM\Mapping\Entity;
>> use Doctrine\ORM\Mapping\Table;
>> use Doctrine\ORM\Mapping\Id;
>> use Doctrine\ORM\Mapping\GeneratedValue;
>> use Doctrine\ORM\Mapping\Column;
>>
>> [Entity::class => []]
>> [Table::class => ['name' => 'foo_table']]
>> class Foo
>> {
>>      [Id::class => []]
>>      [GeneratedValue::class => [GeneratedValue::UUID]]
>>      [Column::class => ['name' => 'bar_column', 'type' => 'string']]
>>      private $bar;
>> }
>>
>
> This looks great indeed for many reasons:
> 1) it's a simple array
> 2) it can be parsed with built-in DSL syntax for PHP, so any arbitrary
> evaluations with constants can be applied transparently, e.g.
> [Loggable::class => ['pointcut' => self::PREFIX . 'test' ]]
>
> 3) C# uses similar syntax with square brackets for annotations:
>
> public class Foo
> {
>      [Display(Name="Product Number")]
>      [Range(0, 5000)]
>      public int ProductID { get; set; }
> }
>
> However, I would like to see simple markers without nested associative
> arrays, e.g just put single AnnotationName::class into brackets or specify
> multiple annotations in one section:
>
> [Entity::class, Table::class => 'foo_table']
> class Foo
> {
>    // ...
> }


One other concern to think about:

In Drupal's case, we have a lot of class annotations.  We use them for 
discovery.  That is, "find me all classes that are a Thingie, and 
relevant metadata about them".  (Where "is a Thingie" is more than just 
"has this interface" in some cases.)  The catch is we need the metadata 
at very different times than we need the code itself; that's why we're 
not just making it a method on the class.

One issue we ran into with the Doctrine parser was that it used 
reflection to get the docblock to parse.  That meant loading an awful 
lot of code that was never actually used in that request, which had a 
not-small performance impact.

In the end, we ended up modifying the parser to tokenize the file rather 
than just loading it; that way we could free the memory used after each 
file rather than holding it around forever, which had a huge memory 
savings for us.


I don't know that's possible if done in the engine itself, nor if the 
always-available opcode cache obviates that concern or to what degree; I 
suppose I am more cautioning to be mindful of the impact of lots of 
annotation use at scale, not just on CPU but on memory.  There are 
plenty of use cases for being interested in the annotations and NOT the 
code itself, and we should make sure that's a supported use case that 
won't blow up at large scale.

--Larry Garfield