Implement PHP attributes

[dstogov]

No description provided.

[HallofFamer]

Umm what is this one? PHP native support for annotation?

[dstogov]

Yes, but it's incomplete yet.

On Wed, Apr 20, 2016 at 4:16 PM -0700, "HallofFamer" <notifications@github.commailto:notifications@github.com> wrote:

Umm what is this one? PHP native support for annotation?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//pull/1878#issuecomment-212648142

[HallofFamer]

I see, so you decide to call it 'attributes', interesting. And the syntax for annotations is <>? How about just ? I doubt angle brackets are used in any existing PHP language construct yet.

[dstogov]

I took syntax from HHVM: https://docs.hhvm.com/hack/attributes/introduction

---

From: HallofFamer notifications@github.com
Sent: Thursday, April 21, 2016 17:59
To: php/php-src
Cc: Dmitry Stogov; Author
Subject: Re: [php/php-src] Implement PHP attributes (#1878)

I see, so you decide to call it 'attributes', interesting. And the syntax for annotations is <>? How about just ? I doubt angle brackets are used in any existing PHP language construct yet.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//pull/1878#issuecomment-212959453

[scaytrase]

https://wiki.php.net/rfc/attributes

Despite of the fact the idea is borrowed from the hack, I'd personally (as a developer) prefer current annotation system over this implementation. The reason are:

• Structural problem
  Hack annotation are not classes or even structs, thus are not structured. There is no built-in validation, no defaults, no semantics, no behavior
• Namespacing problem

Is generated by the previous one.
The Doctrine replacement example shows it well. You should either try to mak ALL attributes as \Doctrine\ORM or to manually filter them all to avoid undefined class exception. Suggested attribute system lacks the namespacing to avoid these situations. I see the namespacing option within the RFC, but it does not sove the problem until attribute is a structural element (class, funciton, whatether)

• Multiplication problem

Also generated by the first one. The problem is that in the moments you want to have two attributes, The RFC advice is to replace the content with array. The structural problem strongly prohibit this behavior as you should check all possible argument formats every time you work with this attributes.
Current annotation system, again, allows you to flexibly decide how to work with several annotations as the Doctrine reader provide you each annotation as a separate instance of some annotation class.

Implementing these feature gives us a simple but really powerfull feature - backward compatibility with the previous annotation format. What's left - is a matter of format, which could be converted automatically using current software readers and AST implementation

[dstogov]

All these problem are solvable by higher layer (like it shown in "Doctrive" example). This RFC proposes just a base functionality in PHP core by design.

[pmukhin]

Hack's developers offered very strange syntax for annotations. It looks like they did it because of that '@' is used to mute errors on functions. But I think this RFC should be based on bests existing implementations like Java's or maybe Python's. Moreover some very useful tools like Doctrine use Java-like syntax for years.

For example:

@ORM\Column(name="id", type="int")
@ORM\GeneratedValue()
private $id;

Looks much better and more acquainted for new developers than this:

<<@ORM\Column(name="id", type="int")>>
<<@ORM\GeneratedValue()>>
private $id;

One more strange thing in Hack is "short" syntax for closures:

($some) ==> { ... }

It is not that short actually...

[scaytrase]

@dstogov The "Doctrine" example only show that all these problems should be solved in almost every attribute processor which allow multiple attributes extended by users.

The solution is to implement software attribute parser which takes FQCN from the attribute name (I'm not sure,but current examples show that it ignores use directives, so you should write fqcn each time you want to reference a class), takes the positional arguments from the attribute and tries to instantiate an attribute class there.

The question - where is the general difference with caching Doctrine Annotation Reader? Annotations are cached, so it reads them very quick, annotations are structured, multivalued. etc.

[dstogov]

I'm tired to repeat - "Doctrine" is not the only use case for attributes, and I'm not going to reimplement Doctrine in C. This RFC provides base functionality for native attribute parsing and storage. Then it may be re-used for extensible passer, design by contract, verification, attribute system, flags for PHP compiler, etc.

[scaytrase]

Doctrine is NOT the USE case. doctrine\annotations is the implementation of annotation mechanism. It's already used in hundreds of software projects, uncluding symfony, zend framework, drupal.

https://www.versioneye.com/php/doctrine:annotations/references (it's the list of the projects, using this directly, and many others use it transitionally).

Making the proposed attributes implementation backward compatible with this mechanism:

• Does not diverge with your ideas of re-using it wherever you want (flags, contracts, verification, etc)
• Will be easier to transfer to (as classes will stay the same, use directives with stay the same, only attribute syntax changes and this could be do by machine)
• Type-strict (attributes are typed, like annotations in Java)

[linaori]

Why can't we just have (something like) Java annotations in PHP? 😢

[nikic]

Closing as https://wiki.php.net/rfc/attributes has been declined, at least for now.