Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Attribute Amendments »

[VOTE] Attribute Amendments

php.internals

Benjamin Eberlei

6 years ago
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

Marco Pivetta

6 years ago
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/

Lester Caine

6 years ago
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

Benjamin Eberlei

6 years ago
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

6 years ago
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

Larry Garfield

6 years ago
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

Lester Caine

6 years ago
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

Benas IML

6 years ago
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:

Benjamin Eberlei

6 years ago
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.

Dan Ackroyd

6 years ago
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

Nikita Popov

6 years ago
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

Benjamin Eberlei

6 years ago
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:

David Rodrigues

6 years ago
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:

Benjamin Eberlei

6 years ago
On Mon, Jun 22, 2020 at 6:57 PM David Rodrigues <david.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.