[RFC] Attributes v2

pon., 9 mar 2020 o 15:45 Benjamin Eberlei kontakt@beberlei.de napisał(a):

On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list
back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

There is also a fair amount of implementation detail still up for debate,
which is noted in "Open Issues". I have pre-committed to one approach,
but
listed alternatives there. On these issues I am looking for your
feedback.

Obviously I am looking for feedback on the whole RFC, not just the open
issues :-)

greetings
Benjamin

Hi Benjamin,

I'm really glad you're taking up the baton!

IMHO a bunch of straw polls could provide a way more beneficial knowledge
about feelings
people who can vote up for this feature. What do you think?

It could be good to discover the negative or positive feelings as well as
"I'm not opposite" feelings.

From what I can see now and I didn't think of it earlier are some details
but we should ask the question
how far we wanna go with this feature for its an initial shape.

Are we gonna provide complete attributes feature like C#, Java etc. which
allows for
annotating annotations (whatever it's called for me annotations/attributes
has no difference for now)
meaning they allow to put metadata which puts restrictions on:

1. Usage of the attribute should be allowed once or multiple times
   regarding the same target?
2. Targetting attributes should be annotated - no matter if through an
   interface or annotation?
3. Allow for inheritance should be annotated - meaning when reading
   attributes for class Bar
   which extends Foo on which attributes are set, should I get attributes or
   not?
4. Should attributes be resolvable all the time, what if the class won't
   exist on runtime?
   In some languages like Java there are for eg. documentary annotations
   which live with code but are not stored on runtime.

Or we simply want to provide a simple way of retrieving the metadata from
class/trait/interface/properties/methods/functions without checking their
repeateness, without inheritance,
without validating the targets where they appear, and just allow to move
any kind of attributes into
the language and allow the userland to decide what to do with them and how
to handle them properly?

The thing which I haven't consider earlier and I find it nice features is
the ability
to filter annotations against some abstract/base annotation - it may be
described as a better cause
I do feel like it should be done through extending of the interface and not
by an abstract class.
Like from the RFC itself the \Validator\Attributes\Attribute::class it
wouldn't make sense for it to be
a class, not even an abstract class, there's probably no method which this
abstract will provide.

Attributes should be forbidden for instantiation and this if funny cause
they do have a public __construct
so they look like classes but are not actually classes which you should be
allowed to instantiate wherever
you want, right? So we agree it looks a little weird here but dunno if
there's something we can do.

cheers,
Michał Brzuchalski

On Mon, Mar 9, 2020 at 5:18 PM Stephen Reay php-lists@koalephant.com
wrote:

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list
back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

There is also a fair amount of implementation detail still up for debate,
which is noted in "Open Issues". I have pre-committed to one approach,
but
listed alternatives there. On these issues I am looking for your
feedback.

greetings
Benjamin

Hi Benjamin,

I can’t comment on the feasibility of this RFC or the patch, but I like
the approach it takes to this ‘problem’. I can already imagine a number of
‘nicer’ ways to achieve similar/same results using this, so thanks for
taking up the baton!

My one small query/request is about the Reflection*::getAttributes
method. Is there a philosophical and/or technological reason for why it can
only ‘filter’ the attributes by a single given name, rather than being
variadic and filtering against multiple names (i.e. returning those that
match any of the given names)? I would imagine many uses (particularly
within libraries) would end up wanting to retrieve multiple attribute types
they’re aware of all at once, no?

The name filtering works when using a common base class or interface, so if
a library has a class "My\BaseAttribute" and all related attributes extend
from it, then in the code you can do:

$attributes = $reflectionClass->getAttributes(\My\BaseAttribute::class);

This would return all attributes matching.

Cheers

Stephen

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

Why do decorator names refer to classes, rather than any callable as in python?

Hi Benjamin,

From the examples, am I to understand that the RFC introduces a top-level
namespace \Php ?

Honestly didn't realize this and thought PhpToken would already be in the
PHP namespace. I am going to think this over and probably go for
PhpAttribute in the global namespace instead. It wasn't my intention to
create a precedent here :)

--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

On Mon, Mar 9, 2020 at 6:18 PM Rowan Tommins rowan.collins@gmail.com
wrote:

Hi Benjamin

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list
back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

Thanks for picking this up again. It's amazing how deeply the integration
of annotations has embedded into PHP without any support from the language,
so this feels long overdue.

One quick suggestion: the use cases currently appear inside the Proposal
heading in the RFC, and some but not all are labelled "not part of the
RFC". It might be useful to have a clearly separate "Possible Use Cases"
header, and a summary somewhere of which interfaces and classes would
actually be provided by the initial implementation.

Thank you, I didn't notice that before in the ToC view, fixed!

Regards,

Rowan Tommins
[IMSoP]

Am 09.03.2020 um 20:16 schrieb Matthew Brown:

I think the syntax here looks great, and I think this would be an exciting
addition to the language. I want to build things with it!

I could not have written better words :)

Another doubt: in relation to the PR (
https://github.com/beberlei/php-src/pull/2) it is called as "attributes",
but seems better keep as "annotations". The Doctrine annotations is based
in PHPDoc, are not? And it is basically the same thing, and annotations
term is used in other languages.

And too, could annotators have some additional features like Typescript
decorators?

Atenciosamente,
David Rodrigues

Em seg., 9 de mar. de 2020 às 16:35, Aleksander Machniak alec@alec.pl
escreveu:

The RFC is at https://wiki.php.net/rfc/attributes_v2

Would it make sense to support this:

<<WithoutArgument>>
<<SingleArgument(0)>>
<<FewArguments('Hello', 'World')>>
function foo() {}

in this form:

<<
WithoutArgument; // comments allowed here
SingleArgument(0);
FewArguments('Hello', 'World');

function foo() {}

or if there's not many attributes, in the same line:

<<WithoutArgument; SingleArgument(0)>>

It may look better for the short version, but I'm not so sure about the
long version.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

The RFC is at https://wiki.php.net/rfc/attributes_v2

Would it make sense to support this:

<<WithoutArgument>>
<<SingleArgument(0)>>
<<FewArguments('Hello', 'World')>>
function foo() {}

in this form:

<<
WithoutArgument; // comments allowed here
SingleArgument(0);
FewArguments('Hello', 'World');

function foo() {}

or if there's not many attributes, in the same line:

<<WithoutArgument; SingleArgument(0)>>

It may look better for the short version, but I'm not so sure about the
long version.

Its certainly possible, the original Attributes v1 RFC supported both
syntaxes. I wanted to simplify it and opted for each attribute to have its
own <<>> enclosing. I have added it to the list of open issues to determine
what approach to take.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

There is also a fair amount of implementation detail still up for debate,
which is noted in "Open Issues". I have pre-committed to one approach, but
listed alternatives there. On these issues I am looking for your feedback.

greetings
Benjamin

I am very excited to see this back, and overall I like the approach!

Thoughts in no special order:

• It's not entirely clear, but the values in an argument-carrying
  attribute are passed to its constructor variadically? Viz:

<<Foo(1, 2, 3)>>
function stuff() {}

class Foo implements Attribute {
public function __construct(int $first, int $second, int $third) { ... }
}

Yes? (And then if you wanted to capture them all you could use a
...$args parameter in the constructor.)

• It looks like the only way to support named parameters would be to
  pass an associative array and decompose it yourself. That's... better
  than nothing I guess but also we're back to the same lack of
  self-documentation we always lament. Is there any opportunity to do
  named parameters in some other way?

• Is it possible to inline a sub-object, or no? Viz, is this legal, or
  would we want it to be legal (I'm assuming it's not at the moment):

<<Foo('a', 'b', Bar('baz'))>>
function stuff() {}

• I really dig how you can filter annotations to just those that
  match a certain parent class/interface. That was one of the nicer
  parts of PSR-14 so I'm really glad to see the same "make the type
  system earn its keep" approach here. It encourages packages to
  interface-tag their annotations so they can easily grab "just theirs".
  +1

• The "more complex Doctrine ORM use-case" example includes inlining
  multiple annotations together: <<ORM\Id, ORM\Column,
  ORM\GeneratedValue>> . Is that just an oops since that possibility was
  only just added to the Open Issues?

Regarding open issues:

• If constant expressions are easy enough to support, I don't see a
  reason not to support them.

• I'm torn on the marker interface. On the one hand, a marker
  interface would make it easier to audit a package for all of its
  attributes; just grep for "implements Attribute". I'm sad that we
  didn't get a marker interface in PSR-14 for that reason. On the other,
  if it doesn't do anything except be a marker then it doesn't really
  offer anything else; and it also potentially makes it harder to add
  some special casing of attributes in the future, say to offer "if you
  want this extra attribute behavior, use this interface/base
  class/whatever." I could go either way here.

• Letting attributes say where they're legal would be a good case for
  such a more-than-marker interface.

• The aforementioned example of specifying where an attribute is legal
  implies that attribute classes can themselves have attributes. True?
  If so, that should be made explicit elsewhere in the RFC. I'm not
  against attribute-ception, but that should be explicit.

I think my only significant pushback at the moment is that attributes
here suffer from the same redundancy problem as any other value object.
To wit:

class Owner implements Attribute {

public readonly string $name;

public readonly string $title;

public readonly int $age;

public function __construct(string $name, string $title, int $age) {
$this->name = $name;
$this->title = $title;
$this->age = $age;
}
}

<<Owner('Larry', 'Manager', 99)>>
function stuff() {}

That necessitates the same quadrupal-repetition that other constructors
have. Since I anticipate the 99% use case to be exactly that, the pain
of that redundancy (and the mandatory unnamed order) will be felt
rather dramatically here and thus hurts ergonomics. Is there no way
that we address that?

I realize the answer may be "no more than any other class, they all
suck equally". Are we at least certain then that if we can solve that
in the future for classes generally that it will automatically work
here? (Eg, if new Owner({name: 'Larry', 'age' => 99, 'title' =>
'Manager'}); became a legal shorthand for the above, it would
automatically work for annotations as well.)

Overall nice work, and I hope to get to use it.

Just for kicks, I decided to see what attributes would look like in Tukio to figure out what using the API would look like. So here's a few possibilities as a test case.

The original code is here:

https://github.com/Crell/Tukio/blob/master/src/ProviderBuilder.php#L69

It's implementing basically the same idea as Symfony's EventSubscriberInterface, for those familiar with it. Only right now you can't set anything directly and have to use a separate callback to have non-default configuration. The intent here is to replace that separate callback with attributes.

Code here:

https://gist.github.com/Crell/22fd255efe389f2eaf01fc89ab1d85d9

In the single attribute version, it works pretty well but it's annoying that the various options have to be in order, and are not self-documenting. I left out the option of before/after ordering instead of priority. I'm not sure how I'd do it there other than making it 3 different annotation classes, but then I'd need to add code to enforce that you use only one of the three.

In the multi-attribute version, it's decent amount more code and it has a type switch in the middle. Interestingly I did it a different way than the RFC's example. I first pulled out the attribute objects en masse, then did an if-elseif dance. The RFC example had a switch on the type property of the reflection object, and then pulled out the actual attribute object itself within each switch case. Neither one seems particularly nice to me.

Finally I did a single attribute version that takes an array parameter to make it more self-documenting. That made it much easier to handle internally, and I was able to add the priority/before/after logic that would have been too annoying to do in the other examples.

Overall thoughts:

The reflection API is annoying, but that doesn't come from annotations.

I'd love to be able to clean up those RTTI statements. Neither the one here nor the one in the RFC now is particularly pleasant. That's possibly out of scope (we are talking about an array of multiple objects of unknown concrete type, so RTTI is probably unavoidable), but I wonder if having Attributes have a base class with some built in functionality (eg, the pieces of the reflection object itself) would be useful? Essentially combining the reflection object and the attribute object so we can skip a step. Just brainstorming here.

Visually as a user of the attribute, I somewhat prefer the multi-attribute version. Not completely, though. I'm still torn.

The array param version seems the most flexible, but also has a lot of sigil-soup going on. And while it does give me a place to do some extra error handling, it has all the same problems that $options parameters always have.

Hopefully this test case is useful and educational. I'd still love to see this get in. (If some of the examples aren't quite clear, let me know.)

--Larry Garfield

On Mon, Mar 9, 2020 at 11:03 PM Larry Garfield larry@garfieldtech.com
wrote:

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list
back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

There is also a fair amount of implementation detail still up for debate,
which is noted in "Open Issues". I have pre-committed to one approach,
but
listed alternatives there. On these issues I am looking for your
feedback.

greetings
Benjamin

I am very excited to see this back, and overall I like the approach!

Thoughts in no special order:

• It's not entirely clear, but the values in an argument-carrying
  attribute are passed to its constructor variadically? Viz:

<<Foo(1, 2, 3)>>
function stuff() {}

class Foo implements Attribute {
public function __construct(int $first, int $second, int $third) { ... }
}

Yes? (And then if you wanted to capture them all you could use a ...$args
parameter in the constructor.)

• It looks like the only way to support named parameters would be to pass
  an associative array and decompose it yourself. That's... better than
  nothing I guess but also we're back to the same lack of self-documentation
  we always lament. Is there any opportunity to do named parameters in some
  other way?

Improvements here are contingent on any named parameters support, which
could

• Is it possible to inline a sub-object, or no? Viz, is this legal, or
  would we want it to be legal (I'm assuming it's not at the moment):

<<Foo('a', 'b', Bar('baz'))>>
function stuff() {}

No thats not possible, because the constant expression syntax doesn't allow
this. See Tysons proposal lately to allow function calls in constant
expressions: https://externals.io/message/108630

• I really dig how you can filter annotations to just those that match a
  certain parent class/interface. That was one of the nicer parts of PSR-14
  so I'm really glad to see the same "make the type system earn its keep"
  approach here. It encourages packages to interface-tag their annotations
  so they can easily grab "just theirs". +1

• The "more complex Doctrine ORM use-case" example includes inlining
  multiple annotations together: <<ORM\Id, ORM\Column, ORM\GeneratedValue>>
  . Is that just an oops since that possibility was only just added to the
  Open Issues?

Ah this is a mistake, I removed that use-case and settled on a single
syntax.

Regarding open issues:

• If constant expressions are easy enough to support, I don't see a reason
  not to support them.

• I'm torn on the marker interface. On the one hand, a marker interface
  would make it easier to audit a package for all of its attributes; just
  grep for "implements Attribute". I'm sad that we didn't get a marker
  interface in PSR-14 for that reason. On the other, if it doesn't do
  anything except be a marker then it doesn't really offer anything else; and
  it also potentially makes it harder to add some special casing of
  attributes in the future, say to offer "if you want this extra attribute
  behavior, use this interface/base class/whatever." I could go either way
  here.

• Letting attributes say where they're legal would be a good case for such
  a more-than-marker interface.

I am not sure. This is something PHP would validate at
Reflection::getAttribute() time, at which time it is also easy to validate
for userland implementations.

• The aforementioned example of specifying where an attribute is legal
  implies that attribute classes can themselves have attributes. True? If
  so, that should be made explicit elsewhere in the RFC. I'm not against
  attribute-ception, but that should be explicit.

Attributes are just PHP classes, so they can indeed have their own
attributes. So a userland library building on top of attributes, could call
getAttributes() then validate that each attribute returned has itself an
attribute that "marks the target":

<<Target(["class"])>>
class Entity
{
}

I think my only significant pushback at the moment is that attributes here
suffer from the same redundancy problem as any other value object. To wit:

class Owner implements Attribute {

public readonly string $name;

public readonly string $title;

public readonly int $age;

public function __construct(string $name, string $title, int $age) {
$this->name = $name;
$this->title = $title;
$this->age = $age;
}
}

<<Owner('Larry', 'Manager', 99)>>
function stuff() {}

That necessitates the same quadrupal-repetition that other constructors
have. Since I anticipate the 99% use case to be exactly that, the pain of
that redundancy (and the mandatory unnamed order) will be felt rather
dramatically here and thus hurts ergonomics. Is there no way that we
address that?

This is not something to fix for this RFC, but any solution here and
attributes can benefit from it as they are just PHP classes.

I realize the answer may be "no more than any other class, they all suck
equally". Are we at least certain then that if we can solve that in the
future for classes generally that it will automatically work here? (Eg, if
new Owner({name: 'Larry', 'age' => 99, 'title' => 'Manager'}); became a
legal shorthand for the above, it would automatically work for annotations
as well.)

Overall nice work, and I hope to get to use it.

--Larry Garfield

Saying "the syntax makes my eyes bleed" is slightly useless feedback.

You could say "it's hard to scan", but I don't even think that's true –
prepending everything << makes it easy to pick out attributes in plain text
at a glance, and one can assume that IDEs will help even further.

Additionally this syntax has effectively been battle-tested at scale
already in PHP-like codebases – thousands of engineers at Facebook and
Slack have used it over the last few years, and been productive with it.

On Mar 9, 2020, at 10:42 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list
back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

There is also a fair amount of implementation detail still up for debate,
which is noted in "Open Issues". I have pre-committed to one approach,
but
listed alternatives there. On these issues I am looking for your
feedback.

greetings
Benjamin

I am very excited to see this. I make heavy use of pseduo-attributes in
both PhpDoc and using class constants, and having real attributes would be
quite the boon.

I do have a few concerns.

1. The syntax makes my eyes bleed.

---

I find angle brackets extremely hard to read and fear — have trained many
newbies in programming — that it will cause newbies who see PHP to think it
is too complex for them to consider learning.

You mention that the good symbols are taken, but why limit ourselves to
symbols? Why not use words like PHP uses for other parts of the language?

So instead of:

<<SingleArgument("Hello")>>
<<Another\SingleArgument("World")>>
<<\My\Attributes\FewArguments("foo", "bar")>>
function foo() {}

Why not use?:

attribute SingleArgument("Hello")
attribute Another\SingleArgument("World")
attribute \My\Attributes\FewArguments("foo", "bar")
function foo() {}

If we don't want to make attribute a keyword, why not this?:

function attribute SingleArgument("Hello")
function attribute Another\SingleArgument("World")
function attribute \My\Attributes\FewArguments("foo", "bar")
function foo() {}

Or?:

function attributes
SingleArgument("Hello"),
Another\SingleArgument("World"),
\My\Attributes\FewArguments("foo", "bar")
function foo() {}

Alternately, why not use this (which is probably the best option IMO)?:

function foo() attributes
SingleArgument("Hello"),
Another\SingleArgument("World"),
\My\Attributes\FewArguments("foo", "bar") {}

2. How do your attributes relate to traits and interfaces?

---

I assume that anything you could do in a class you could do in a trait,
but what about interfaces?

Using my syntax, could we have attributes defines in an interface and then
require them to be implemented? For example,

interface Storable attributes
StorageEngine(string $engine),
DoNotTestMethodsPrefixedWith(string $prefix){
function store() attributes PermissionsRequired(string $role) {}
}

When implemented that might look like this:

class AdminOnly() implements Storable attributes
StorageEngine("mongodb"),
DoNotTestMethodsPrefixedWith("_"){
function store() attributes PermissionsRequired("admin") {}
...
}

Other than those two concerns, I'm sold!

-Mike

I find angle brackets extremely hard to read

You're definitely not alone in disliking the syntax, but I think it
actually looks quite neat. It reminds me firstly of templating languages
which use {{foo}} for placeholders and/or keywords, and secondly of French
quote marks, «guillemets». It looks ugly in e-mails using variable-width
fonts, but that's not we're going to be writing code in every day.

and fear — have trained many newbies in programming — that it will cause
newbies who see PHP to think it is too complex for them to consider
learning.

I think the concept of attributes carries a much higher risk of that than
any particular syntax. The same is true of things like generators, or
traits, which use a more verbose syntax, but take a while to grasp.

You mention that the good symbols are taken, but why limit ourselves to
symbols? Why not use words like PHP uses for other parts of the language?

I guess the same question can be asked of any sigils and operators - why do
we write "$foo->bar($a)" rather than "on foo call $bar with $a"? In the
end, there's a trade-off: too many symbols become hard to remember, and
hard to read close together; too many keywords become hard to read at a
glance, and tedious to write.

Alternately, why not use this (which is probably the best option IMO)?:

function foo() attributes
SingleArgument("Hello"),
Another\SingleArgument("World"),
\My\Attributes\FewArguments("foo", "bar") {}

This particular example leads to complications with how different keywords
stack up; would the return statement come before the "attributes" keyword?
if attributes were allowed on anonymous functions, would they come before
or after the use () clause? The traditional placement above the declaration
line keeps attributes out of the way of the main information about the
function.

It's also worth noting that all the other languages referenced in the RFC
use punctuation, rather than keywords, for their equivalent functionality:

C#: [Foo]
Rust: #![Foo] or #[Foo]
C++: [[Foo]]
Java: @Foo
ECMAScript (proposed): @Foo
Go: Foo or "Foo"
Doctrine et al: /** @Foo */
Hack: <<Foo>>

That doesn't mean PHP couldn't buck the trend and use a keyword instead,
but we'd need a strong reason to do so.

Regards,

Rowan Tommins
[IMSoP]

Hi everyone,

I have updated the RFC with much of the feedback received here, on Twitter
and Reddit.

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

Hi Benjamin,

Thanks a lot for you effort, same for Martin. I really hope to see this in PHP8.

I have a simple question. From the RFC:

Attributes are added before the declaration they belong to, similar to do-block comments. They can be declared before or after a doc-block comment that documents a declaration.

Could annotations be declared before AND after the doc-block?
What would be the behavior in that case?

Regards,
Iván Arias.

Hi Benjamin,

I have updated the RFC with much of the feedback received here, on Twitter

and Reddit.

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

Thanks for the update and for giving this a try!

I'm wondering about nested annotations: as you know, they're quite common
in apps that use doctrine/annotation.
How do you think these should be migrated to the new system?

Nicolas

Hi everyone,

I have updated the RFC with much of the feedback received here, on Twitter
and Reddit.

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

The following changes were made:

• Changed to support the same attribute multiple times on the same
  declaration
• Added support for attributes on method and function parameters
• Replaced PhpAttribute interface with an attribute instead
• Distinction between userland and compiler attributes and description
  when each of them gets evaluated/validated
• Reduce number of examples to shorten RFC a bit and expand the other
  examples instead
• Introduced validation of compiler attributes at compile time using a C
  callback
• Offer alternative syntax “@:” using new token T_ATTRIBUTE which will
  be included with a secondary vote

You may have seen me mentioning that I don't want to deviate from the <<>>
syntax, a topic of heated debate. As Martin helped me tremendously with the
RFC and patches he earned to propose an alternative (including patch with
prototype). So we will have a secondary vote on syntax being either
<<Attribute>> or @:Attribute.

Let us know what you think about the changes.

greetings
Benjamin

This looks lovely and I look forward to being able to use it!

Questions:

1. Why is exact-match the default for getAttributes(), and "instanceof" an extra flag? I would expect it to the other way around. The whole point of LSP is that any subclass is a viable replacement for its parent; if not, You're Doing It Wrong(tm). It also means that requesting by interface mandates adding the second parameter or else it will always return nothing. What is the reason for not making instanceof the default match and offering an EXACT opt-in mode?

2. Regarding sub-annotations, can you still do classes as parameters even if not as an annotation marker? Eg:

<<Foo(1, "B", Bar('blah'))>>
function foo()

Or is that also a no-go?

3. I see the most common case for attributes being getting the object version. With the reflection API as currently described, I see two shortcomings.

A) I can't tell if an attribute has a valid object or not before trying to access it, which would presumably fail spectacularly. I believe we need a way to know if getObject() is going to return a valid value before trying to call it. I think this is a hard-requirement.

B) Related, as is getting all attributes as objects looks to be rather clunky.

$attribute_objectgs = array_filter(array_map(function(ReflectionAttribute $r) {
if ($r->getObject()) { // Needs something better here.
return $r->getObject();
}
}, $obj->getAttributes()));

That's gross. :-) Can "get all the attributes that can be formed into objects" be its own operation? $obj->getAttributeObjects() or some such, that skips over non-instantiable attributes and instantiates the rest?

This isn't a requirement, but without it I predict virtually everyone using attributes is going to have to recreate the knot of code above.

Thanks again!

--Larry Garfield

As there has only been minimal new discussion after the last changes to the
RFC I wanted to give a heads up that I will open the vote on Monday
afternoon.

If you have further remarks or questions about the RFC, please let me know.

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

Hi Benjamin,

Thanks for working on this RFC. I have a couple questions and
thoughts about the proposed syntax options.

First, the RFC says that the alternate T_ATTRIBUTE @: token has the
downside "that it does not permit whitespace in attribute names to
allow detecting the ending of the declaration." Can you provide an
example of an attribute name containing whitespace that would be allowed
with the shift left/right tokens but not with the attribute token?

The RFC says that "Semantically the attribute declaration should be
read as instantiating a class with the attribute name and passing
arguments to the constructor." But class names can't contain spaces,
so how is it a downside for attribute names to not permit them either?
It seems like it would be a massive footgun to allow attribute names
that can't resolve to a class name, since there would be no way to
migrate them to a declared attribute class without a BC break. For this
reason, regardless of the final syntax choice I think whitespace should
not be permitted in attribute names.

Secondly, given that attribute arguments are evaluated as constant
expressions, it's far easier for me to read the T_ATTRIBUTE @: syntax
at a glance than the syntax reusing shift left/right tokens. With the
latter my eyes tend to confuse shift left/right tokens in a constant
expression with the open/close token of an attribute (especially since
the syntax using bit shift tokens allows multiple attribute declarations
on the same line).

Consider this example using the shift left/right token syntax:

<<BitShiftExample(4 >> 1, 4 << 1)>><<OtherAttribute(4 >> 1, 4 << 1)>>
function foo() {}

To me the same thing using the T_ATTRIBUTE syntax is far more readable:

@:BitShiftExample(4 >> 1, 4 << 1)
@:OtherAttribute(4 >> 1, 4 << 1)
function foo() {}

Best regards,
Theodore

Hey Benjamin,

I haven't really followed the discussion, so sorry if anything I'm
writing has already been discussed.

Attributes / annotations are one of the two things I currently miss
most in PHP (the other being generics), so thanks for the work on
that!

There are a few points that seem odd to me, I'll start with the "Php" prefix:

<?php

namespace My\Attributes;

use PhpAttribute;

<<PhpAttribute>>
class SingleArgument
{
    public $value;

    public function __construct(string $value)
    {
        $this->value = $value;
    }
}

I think this should be <<Attribute>> instead, if we go with that
syntax. However, I'd even propose another syntax, as attributes aren't
ordinary classes, I'm not sure whether they should be instantiatable
from userland and / or be able to use inheritance, especially as
constructors in PHP aren't subject to variance rules. I guess the
INSTANCE_OF filter also changes whether the attributes are autoloaded
or not?

I expect annotations to be readonly, which classes as outlined in the
RFC cannot currently enforce in PHP. A syntax similar to interfaces
might be appropriate, I'm not sure whether that has been discussed:

<?php

namespace My\Attributes;

attribute SingleArgument
{
    public function value(): string;
}

Such a Java-like syntax would unfortunately only work with some kind
of named parameters.

Finally, the naming of "getAsObject" should IMO be improved,
especially if I read the RFC correctly and autoloading and constructor
invocation is performed by this method. I think "createObject" or
"toObject" might be better names.

In summary, I'd probably vote "no" on the current proposal, even if
it's one of the most missed features, because I think we can do
better, and there's only one chance.

Best,
Niklas

Am Fr., 17. Apr. 2020 um 12:49 Uhr schrieb Benjamin Eberlei
kontakt@beberlei.de:

As there has only been minimal new discussion after the last changes to the
RFC I wanted to give a heads up that I will open the vote on Monday
afternoon.

If you have further remarks or questions about the RFC, please let me know.

Hi all,

I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
2016 with a few changes, incorporating feedback from the mailing list back
then and from talking to previous no voters.

The RFC is at https://wiki.php.net/rfc/attributes_v2

A working patch is at https://github.com/beberlei/php-src/pull/2 though
work around the details is still necessary.

The RFC contains a section with common criticism and objections to
attributes, and I hope to have collected and responded to a good amount
already from previous discussions.

There is also a fair amount of implementation detail still up for debate,
which is noted in "Open Issues". I have pre-committed to one approach, but
listed alternatives there. On these issues I am looking for your feedback.

greetings
Benjamin