[VOTE] Attribute Amendments

On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk
mailto:lester@lsces.uk> 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

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 at 11:11 AM Lester Caine <lester@lsces.uk
mailto:lester@lsces.uk> 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

On Mon, Jun 8, 2020 at 11:11 AM Lester Caine <lester@lsces.uk
mailto:lester@lsces.uk> 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