Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92836
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain webstart.fr from 209.85.161.180 cause and error)
MIME-Version: 1.0
Sender: pierrick@webstart.fr
In-Reply-To: <572069DD.9010708@zend.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>
	<572069DD.9010708@zend.com>
Date: Wed, 27 Apr 2016 07:58:27 -0400
Message-ID: <CAOfKkdQz6AGoOYP2gjTj53DXOSzOeKH6tRtBp36-VUJkftFBCQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Dominic Grostate <codekestrel@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0b0854b072ce053176209a
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: pierrick@adoy.net (Pierrick Charron)

--94eb2c0b0854b072ce053176209a
Content-Type: text/plain; charset=UTF-8

On 27 April 2016 at 03:27, Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> 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>
> 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 maybe right, but the RFC was rejected 5 years ago and sometime people
change their mind, that's why I want to get people thought about it as of
today. If people still think the same that's fine with me, I'm just
exposing for people new to it other possibilities.


>
> 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...
>

I agree that this would increase the complexity of the patch but from time
to time we have to do complex things :-) the Zend Engine is full of them
and even if I agree that this should be avoided if possible it's sometime a
necessity. But again this is just my opinion and I'll respect the
community's decision.


>
> 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
>
>
>

--94eb2c0b0854b072ce053176209a--