Re: [PHP-DEV] [VOTE] Attribute Amendments

[Nikita Popov]

On Mon, Jun 8, 2020 at 10:13 AM Benjamin Eberlei 
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

Re: [PHP-DEV] [VOTE] Attribute Amendments

[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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Benjamin Eberlei]

On Mon, Jun 8, 2020 at 6:48 PM Lester Caine  wrote:

> On 08/06/2020 16:30, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  > > 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
>
>

Re: [PHP-DEV] [VOTE] Attribute Amendments

[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  wrote:

> On 08/06/2020 16:30, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  > > 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
>
>

Re: [PHP-DEV] [VOTE] Attribute Amendments

[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  > > 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Lester Caine]

On 08/06/2020 16:30, Benjamin Eberlei wrote:



On Mon, Jun 8, 2020 at 11:11 AM Lester Caine > 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

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Benjamin Eberlei]

On Mon, Jun 8, 2020 at 11:11 AM Lester Caine  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
>
>

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Dan Ackroyd]

On Mon, 8 Jun 2020 at 09:13, Benjamin Eberlei  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Attribute Amendments

[Marco Pivetta]

Hey Benjamin,

On Mon, Jun 8, 2020 at 10:13 AM Benjamin Eberlei 
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/

[PHP-DEV] [VOTE] Attribute Amendments

[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