Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92833
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.138 as permitted sender)
To: Pierrick Charron <pierrick@adoy.net>, Dominic Grostate
	<codekestrel@googlemail.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
 <CAFMT4NrAshwagmGr6RcadbnLGoe71huA7yYcLYhW-Yf7ohFHGg@mail.gmail.com>
 <571DD94B.3060604@zend.com> <571E63D0.8080800@gmail.com>
 <9c24f969-cb0e-cb46-a23c-6e06e7de7d79@gmail.com> <571E7C08.6010309@gmail.com>
 <571F1B95.9030203@zend.com>
 <CAFKaYMqbPiHsWJpSKLgV-Yvtpwz9MiA_U243=NRtaTtOrXs+fw@mail.gmail.com>
 <CAFKaYMpzuA6suSDascKppspwAnqSpVviY9J01B=NqbpUfBUqJA@mail.gmail.com>
 <CAFKaYMpTM9VNkAUAKPqbDFjf+3AgJu1Yw1x_rR5-TOp64AjctA@mail.gmail.com>
 <CY1PR0201MB17867883CAF70F426788E531BF630@CY1PR0201MB1786.namprd02.prod.outlook.com>
 <CAOfKkdQa7o-WUh5PB+KVnKxwwjtCXuMX0MQUrnOycNCXfePrCg@mail.gmail.com>
 <CAFKaYMq4Z+Lv3j+ds=pc6iOK43fNCaz0cJX3tOt1WA0k2hpv5Q@mail.gmail.com>
 <CAOfKkdQ3t6qgKKFdR4ipaUSh53f1X8UTT2+SXHeoid4QwY7QXQ@mail.gmail.com>
CC: PHP internals <internals@lists.php.net>
Message-ID: <572069DD.9010708@zend.com>
Date: Wed, 27 Apr 2016 10:27:25 +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: <CAOfKkdQ3t6qgKKFdR4ipaUSh53f1X8UTT2+SXHeoid4QwY7QXQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080600030104060309060604"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2016 07:27:33.7488 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1782
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)

--------------080600030104060309060604
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit



On 04/27/2016 08:25 AM, Pierrick Charron wrote:
> Hi all,
>
> First of all thanks dmitry for your great work and for bringing the 
> RFC back to life.
>
> I think it would be great to allow users to define their own 
> annotations and give them some structure (what the annotation is made 
> of). For example let's say I apply an annotation to define that a 
> property is a string with a length. In the proposed RFC I will have 
> something like this :
>
> class Foo {
>     <<MyAnnotation\StringLength(10)>>
> public string $bar;
> }
>
> But how could i know for example that StringLength can take an extra 
> parameters I would have to read the code of the annotation framework 
> see how it parse, use it etc... But if I can define the structure 
> (this is a quickly invented pseudo syntax and I'm not proposing it)
>
> annotation MyAnnotation\StringLength {
> private int $length;
> private string $comment = "Default value";
> }
>
> With this definition I know that the Annotation take 2 parameters one 
> int and one string, that the comment has a default value and can be 
> omitted etc...
>
> Also what I dislike about using a simple array with no definition is 
> that you can't annotate an annotation since there is no definition. I 
> know it can look complex but think about the power you can add to the 
> system. It would help us solve some problems that could not be solved 
> (or at least I can't see any way of doing it) if you can't have a 
> definition you can't attach behaviour/metadata to it.
>
> Here are some problems we could solve (those are just examples)
>
> 1. Are annotations inhereted or not ? Some will say yes, some now but 
> I think they actually both make sense. For example we could imagine 
> that if I annotate a method of my interface as deprecated I want it to 
> be inhereted because all implementations are, but author annotation 
> should not be inherited because I'm not necessarily the author of the 
> implementation. So we could say that annotations are by default not 
> inherited and we could have an <<inherited>> annotation
>
> <<inherited>>
> annotation deprecated {
> }
>
> annotation author {
> public string $name;
> public string $mail;
> }
>
> 2. Is a specific kind of annotation applicable to only one kind of 
> statement or multiple ? JIT don't make sense on a property...
>
> <<Target(Target::METHOD)>>
> annotation jit {
> }
>
> 3. Current version of the RFC propose that we could either have AST or 
> to execute the AST but we could imagine to get both
>
> annotation assert {
> <<AST>>
> public ast\node $node;
> public string $message;
> }
>
> Again, this is just a couple of quick ideas, but this would make 
> things less magic/obscure with a definition and far more flexible. If 
> we agree that we want a definition we could work on how to create this 
> definition (we could use some stuff from the old Annotations RFC 
> https://wiki.php.net/rfc/annotations?rev=1302087566) to update this 
> one with a new syntax or use interface as proposed in the first 
> implementation
>
> class Deprecated implements Annotation {
> }
>
> Maybe

didn't you think, that these annotation over-design made your RFC fail?

You can't create objects at compile-time, and should delay their 
creation until Reflection*::getAttributes().
Returning objects directly form Reflection*::getAttributes() doesn't 
improve flexibility at all.
This would just increase the complexity of the patch...

As I already said many times, all this extensions are possible to do in 
few PHP lines on top of base functionality.
See "Doctrine use-case" at https://wiki.php.net/rfc/attributes#use_cases

If you add these extensions directly into PHP implementation in C, 
you''ll have to support them, and you'll always miss some needs for 
"last use-case", but you won't able to change PHP behavior between major 
PHP versions.

Thanks. Dmitry.

>
> Pierrick


--------------080600030104060309060604--