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
