On 27 April 2016 at 03:27, Dmitry Stogov <dmi...@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
>
>
>
