[VOTE] Attribute Amendments

  110416
June 8, 2020 08:12 kontakt@beberlei.de (Benjamin Eberlei)
Hello internals,

I have opened voting for four different amendments to the Attributes RFC

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

The voting period ends at 2020-06-22 8:00 UTC.

greetings
Benjamin
  110417
June 8, 2020 08:44 ocramius@gmail.com (Marco Pivetta)
Hey Benjamin,

On Mon, Jun 8, 2020 at 10:13 AM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> Hello internals, > > I have opened voting for four different amendments to the Attributes RFC > > https://wiki.php.net/rfc/attribute_amendments > > The voting period ends at 2020-06-22 8:00 UTC. > > greetings > Benjamin >
I was mostly conflicted around the "allow grouped attributes" bit, but James Titcumb (who currently cannot write to this list due to bounced emails) convinced me that it is a good replacement for `/**` and `*/`: << Foo, Bar,
>>
I'm mostly worried that people will do a mess like with grouped use statements, but hopefully we can fix that via CS rules :-) Overall, good improvement! Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  110418
June 8, 2020 09:11 lester@lsces.uk (Lester Caine)
On 08/06/2020 09:44, Marco Pivetta wrote:
> I was mostly conflicted around the "allow grouped attributes" bit, but > James Titcumb (who currently cannot write to this list due to bounced > emails) convinced me that it is a good replacement for `/**` and `*/`:
If twenty years of documentation provided by docblocks is to be replaced there has to be a compelling reason to do so and while this latest drive for yet another documentation method seems to be now a fate acompli there WAS no reason to replace that perfectly acceptable documentation! -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
  110426
June 8, 2020 15:30 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk> wrote:

> On 08/06/2020 09:44, Marco Pivetta wrote: > > I was mostly conflicted around the "allow grouped attributes" bit, but > > James Titcumb (who currently cannot write to this list due to bounced > > emails) convinced me that it is a good replacement for `/**` and `*/`: > > If twenty years of documentation provided by docblocks is to be replaced > there has to be a compelling reason to do so and while this latest drive > for yet another documentation method seems to be now a fate acompli > there WAS no reason to replace that perfectly acceptable documentation! >
Attributes are not documentation (they could theoretically be used for it, but its not the intented use-case). Attributes are supposed to be used with Runtime Reflection to have an effect on the program. Their existence does not supersede docblocks, only the use of docblocks for meta-programming (essentially doing what Attributes allows with docblocks).
> > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  110431
June 8, 2020 16:47 lester@lsces.uk (Lester Caine)
On 08/06/2020 16:30, Benjamin Eberlei wrote:
> > > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk > <mailto:lester@lsces.uk>> wrote: > > On 08/06/2020 09:44, Marco Pivetta wrote: > > I was mostly conflicted around the "allow grouped attributes" > bit, but > > James Titcumb (who currently cannot write to this list due to bounced > > emails) convinced me that it is a good replacement for `/**` and > `*/`: > > If twenty years of documentation provided by docblocks is to be > replaced > there has to be a compelling reason to do so and while this latest > drive > for yet another documentation method seems to be now a fate acompli > there WAS no reason to replace that perfectly acceptable documentation! > > > Attributes are not documentation (they could theoretically be used for > it, but its not the intented use-case). > > Attributes are supposed to be used with Runtime Reflection to have an > effect on the program. > > Their existence does not supersede docblocks, only the use of docblocks > for meta-programming (essentially doing what Attributes allows with > docblocks).
So the statement that "it is a good replacement for `/**` and `*/`" is not correct ... it may be that others do not understand the difference? Personally none of this is addressing the fundamental problem of providing a generic variable system that can manage range as well as 'type' ... something the docblock have been providing for a long time and moving part of that to some new element is only making things worse :( -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
  110433
June 8, 2020 18:37 larry@garfieldtech.com ("Larry Garfield")
On Mon, Jun 8, 2020, at 11:47 AM, Lester Caine wrote:
> On 08/06/2020 16:30, Benjamin Eberlei wrote: > > > > > > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk > > <mailto:lester@lsces.uk>> wrote: > > > > On 08/06/2020 09:44, Marco Pivetta wrote: > > > I was mostly conflicted around the "allow grouped attributes" > > bit, but > > > James Titcumb (who currently cannot write to this list due to bounced > > > emails) convinced me that it is a good replacement for `/**` and > > `*/`: > > > > If twenty years of documentation provided by docblocks is to be > > replaced > > there has to be a compelling reason to do so and while this latest > > drive > > for yet another documentation method seems to be now a fate acompli > > there WAS no reason to replace that perfectly acceptable documentation! > > > > > > Attributes are not documentation (they could theoretically be used for > > it, but its not the intented use-case). > > > > Attributes are supposed to be used with Runtime Reflection to have an > > effect on the program. > > > > Their existence does not supersede docblocks, only the use of docblocks > > for meta-programming (essentially doing what Attributes allows with > > docblocks). > > So the statement that "it is a good replacement for `/**` and `*/`" is > not correct ... it may be that others do not understand the difference? > Personally none of this is addressing the fundamental problem of > providing a generic variable system that can manage range as well as > 'type' ... something the docblock have been providing for a long time > and moving part of that to some new element is only making things worse :(
That... is not related? This is *not* a documentation tool. At all. It's more akin to moving Doctrine Annotations into core (junior version thereof). It doesn't render docblocks redundant, it renders "using docblocks for custom metaprogramming" redundant, which was always a fugly hack to begin with. A type system improvement for "this parameter must be a positive integer less than 50" would be super nice, I agree, but is in no way related to the topic at hand at all. --Larry Garfield
  110443
June 9, 2020 09:22 lester@lsces.uk (Lester Caine)
On 08/06/2020 19:37, Larry Garfield wrote:
> That... is not related? This is*not* a documentation tool. At all. It's more akin to moving Doctrine Annotations into core (junior version thereof). It doesn't render docblocks redundant, it renders "using docblocks for custom metaprogramming" redundant, which was always a fugly hack to begin with. > > A type system improvement for "this parameter must be a positive integer less than 50" would be super nice, I agree, but is in no way related to the topic at hand at all.
But at the end of the day, THAT has been the problem all along with people insisting on 'strong typing'. Surly the 'topic in hand' SHOULD be to address the base level variables and create a base that replaces the material that many of us of have used docblocks to provide for years, and which most decent IDE's display currently without needing to add more work understanding new 'ways'. A variable that may or may not be NULL, read only, integer, numeric, string and so on with size and length restrictions automatically managed ... the code for which is permanently loaded and not being rebuilt every time a different 'version' of a variable is loaded. The sort of facility that every database interface tries to emulate when interchanging persistent data with a database value, and an array of which consistently defines a record as a group of variables. Grouping those variables to provide objects which simply manages the relations between them. I suppose the real question is if PHP is a script processor or a compiler? If people want a complied program, then use C/C++ direct! Leave PHP as a script processor and restore one of the main reasons PHP worked so well long ago ... it provided a well managed library of scripts for doing the basic jobs that have not changed since day one. I seem to recall a recent request for BUILDING such a library? But that is exactly what PEAR has provided for years. It's just not well maintained these days simply because it requires a hell of a lot of work to 'bring it up to date with PHP7.x' as does a lot of the legacy code base :( Yet amazingly 99% of that legacy code DOES still run ... just throwing errors that may well simply be ignored. PHP8 is yet another push to make PHP 'more modern' but is it ACTUALLY making PHP better or do we have precisely the same problem as Python but trying to change things piecemeal rather than just going all in and destroying BC and starting again with 'a more current language'? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
  110434
June 8, 2020 18:41 benas.molis.iml@gmail.com (Benas IML)
Hey,

I'm not sure what you're referring to as "generic variable system" but
given that you mentioned "type", I assume you mean typed variables? If so,
PHP is never going to have typed variables due to performance implications.

As for the `/**` and `*/`, I believe Marco was talking about Doctrine
Annotations. For example, instead of writing this:

```
/**
 * @Route("/users", methods={"GET"})
 * @OtherAnnotation
 */
```

....we would write:

```
<<
    Route("/users", ["GET"]),
    OtherAnnotation
>> ```
Best regards, Benas On Mon, Jun 8, 2020, 7:47 PM Lester Caine <lester@lsces.uk> wrote:
> On 08/06/2020 16:30, Benjamin Eberlei wrote: > > > > > > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk > > <mailto:lester@lsces.uk>> wrote: > > > > On 08/06/2020 09:44, Marco Pivetta wrote: > > > I was mostly conflicted around the "allow grouped attributes" > > bit, but > > > James Titcumb (who currently cannot write to this list due to > bounced > > > emails) convinced me that it is a good replacement for `/**` and > > `*/`: > > > > If twenty years of documentation provided by docblocks is to be > > replaced > > there has to be a compelling reason to do so and while this latest > > drive > > for yet another documentation method seems to be now a fate acompli > > there WAS no reason to replace that perfectly acceptable > documentation! > > > > > > Attributes are not documentation (they could theoretically be used for > > it, but its not the intented use-case). > > > > Attributes are supposed to be used with Runtime Reflection to have an > > effect on the program. > > > > Their existence does not supersede docblocks, only the use of docblocks > > for meta-programming (essentially doing what Attributes allows with > > docblocks). > > So the statement that "it is a good replacement for `/**` and `*/`" is > not correct ... it may be that others do not understand the difference? > Personally none of this is addressing the fundamental problem of > providing a generic variable system that can manage range as well as > 'type' ... something the docblock have been providing for a long time > and moving part of that to some new element is only making things worse :( > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  110435
June 8, 2020 19:06 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Jun 8, 2020 at 6:48 PM Lester Caine <lester@lsces.uk> wrote:

> On 08/06/2020 16:30, Benjamin Eberlei wrote: > > > > > > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk > > <mailto:lester@lsces.uk>> wrote: > > > > On 08/06/2020 09:44, Marco Pivetta wrote: > > > I was mostly conflicted around the "allow grouped attributes" > > bit, but > > > James Titcumb (who currently cannot write to this list due to > bounced > > > emails) convinced me that it is a good replacement for `/**` and > > `*/`: > > > > If twenty years of documentation provided by docblocks is to be > > replaced > > there has to be a compelling reason to do so and while this latest > > drive > > for yet another documentation method seems to be now a fate acompli > > there WAS no reason to replace that perfectly acceptable > documentation! > > > > > > Attributes are not documentation (they could theoretically be used for > > it, but its not the intented use-case). > > > > Attributes are supposed to be used with Runtime Reflection to have an > > effect on the program. > > > > Their existence does not supersede docblocks, only the use of docblocks > > for meta-programming (essentially doing what Attributes allows with > > docblocks). > > So the statement that "it is a good replacement for `/**` and `*/`" is > not correct ... it may be that others do not understand the difference? > Personally none of this is addressing the fundamental problem of > providing a generic variable system that can manage range as well as > 'type' ... something the docblock have been providing for a long time > and moving part of that to some new element is only making things worse :( >
Ah I think i understand where you come from, the original wording from Marco was I believe meant to explain only an analogy that <<>> can be seen as enclosement similar to /** */ in docblocks.
> > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  110419
June 8, 2020 09:41 Danack@basereality.com (Dan Ackroyd)
On Mon, 8 Jun 2020 at 09:13, Benjamin Eberlei <kontakt@beberlei.de> wrote:
> > I have opened voting for four different amendments to the Attributes RFC > > https://wiki.php.net/rfc/attribute_amendments
To explain a 'no' vote.
> Should a secondary grouped syntax for attributes be introduced?
Voted no, as it's not obviously required, and can be added later. Also, we aren't that good at designing the 'group' syntax. See group use for a bad example.
> Should attributes allow definition of repeatability? > Should attributes allow definition of target declarations?
Voted no for both, as they can be enforced in userland, or be added to core later if some reason for why they must be in core is found. cheers Dan Ack
  110511
June 15, 2020 09:07 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jun 8, 2020 at 10:13 AM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> Hello internals, > > I have opened voting for four different amendments to the Attributes RFC > > https://wiki.php.net/rfc/attribute_amendments > > The voting period ends at 2020-06-22 8:00 UTC. > > greetings > Benjamin >
On the constructor promotion thread, you briefly suggested that it might make sense to move attribute validation from the newInstance() call, to fetching the attributes, and instead provide a flag to fetch unvalidated attributes. Have you given any further consideration to that approach? Regards, Nikita
  110698
June 22, 2020 16:38 kontakt@beberlei.de (Benjamin Eberlei)
Hello,

The voting period is over and all four votes have been accepted:

- Rename PhpAttribute to Attribute
- Allow grouped syntax (though this will probably be obsolete looking at @@
syntax currently winning the re-vote)
- Attribute targets
- Attribute repeatability

Thank you everyone!

On Mon, Jun 8, 2020 at 10:12 AM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> Hello internals, > > I have opened voting for four different amendments to the Attributes RFC > > https://wiki.php.net/rfc/attribute_amendments > > The voting period ends at 2020-06-22 8:00 UTC. > > greetings > Benjamin >
  110699
June 22, 2020 16:57 david.proweb@gmail.com (David Rodrigues)
I like to suggest that, by default, attributes could be repeatable, so we
can disable this instead (eg. "@@ Attribute(self::IS_UNIQUE)").


Atenciosamente,
David Rodrigues


Em seg., 22 de jun. de 2020 às 13:38, Benjamin Eberlei <kontakt@beberlei.de>
escreveu:

> Hello, > > The voting period is over and all four votes have been accepted: > > - Rename PhpAttribute to Attribute > - Allow grouped syntax (though this will probably be obsolete looking at @@ > syntax currently winning the re-vote) > - Attribute targets > - Attribute repeatability > > Thank you everyone! > > On Mon, Jun 8, 2020 at 10:12 AM Benjamin Eberlei <kontakt@beberlei.de> > wrote: > > > Hello internals, > > > > I have opened voting for four different amendments to the Attributes RFC > > > > https://wiki.php.net/rfc/attribute_amendments > > > > The voting period ends at 2020-06-22 8:00 UTC. > > > > greetings > > Benjamin > > >
  110700
June 22, 2020 18:49 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Jun 22, 2020 at 6:57 PM David Rodrigues proweb@gmail.com>
wrote:

> I like to suggest that, by default, attributes could be repeatable, so we > can disable this instead (eg. "@@ Attribute(self::IS_UNIQUE)"). > > during research we found that most of the attributes really have to be
unique, and only a small number is usually repeatable. So making them unique by default and only repeatable on request is the better approach.
> > Atenciosamente, > David Rodrigues > > > Em seg., 22 de jun. de 2020 às 13:38, Benjamin Eberlei < > kontakt@beberlei.de> escreveu: > >> Hello, >> >> The voting period is over and all four votes have been accepted: >> >> - Rename PhpAttribute to Attribute >> - Allow grouped syntax (though this will probably be obsolete looking at >> @@ >> syntax currently winning the re-vote) >> - Attribute targets >> - Attribute repeatability >> >> Thank you everyone! >> >> On Mon, Jun 8, 2020 at 10:12 AM Benjamin Eberlei <kontakt@beberlei.de> >> wrote: >> >> > Hello internals, >> > >> > I have opened voting for four different amendments to the Attributes RFC >> > >> > https://wiki.php.net/rfc/attribute_amendments >> > >> > The voting period ends at 2020-06-22 8:00 UTC. >> > >> > greetings >> > Benjamin >> > >> >