Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Michał Marcin Brzuchalski]

Hi Paul,

wt., 28 lip 2020 o 20:56 Paul M. Jones  napisał(a):

> ...
> Let's count. + is "change away from @@ to anything else", - is "stay with
> @@", ? is hard-to-tell/weak/uncertain/they-all-suck.
> ...
> Michal Brzuchalski: -?
>

Wow. Hold on your horses. I was never in favour for @@ but always against
at least AFAIR.
Where did you get that?

Anyway it should be ++ here


>
> ++: 13 definitely prefer changing to something other than @@ (though not
> necessarily #[])
>

++: 14 definitely prefer changing to something other than @@ (though not
necessarily #[])


> +?: 10 probably prefer changing to something other than @@ (though not
> necessarily #[])
> ??: 23 hard-to-tell/weak/uncertain/they-all-suck
> -?: 3 probably prefer to keep @@
>

-?: 2 probably prefer to keep @@

--: 4 definitely prefer to keep @@
>

 It's hard to rely fully on your statement considering such a mistake.

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM is terrible, are we sure we're OK with it?

[Walter Parker]

We read phil's post years ago (it is from 2013).
Do you have anything new to contribute to the discourse other than
posting a link to a post from 7 years ago?

If so, you should present that and not old web pages .


Walter

On Tue, Jul 28, 2020 at 7:31 PM Ryan Jentzsch  wrote:
>
> https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/



-- 
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.   -- Justice Louis D.
Brandeis

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

[PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM is terrible, are we sure we're OK with it?

[Ryan Jentzsch]

https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Benjamin Eberlei]

Hi Joe,

Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
revoting.

The arguments the RFC brings forward don't convince me that we should pick
#[] over @@.

1. The parser conflict was my major reason why @@ should not have been
picked from a technical POV. But this issue has been fixed by an
independent improvement since then. These kinds of small problems are found
regularly after RFCs are accepted and are subsequently fixed. The RFC is
formulated as the problem still exists, but it does not. Yes, the namespace
token RFC vote has not yet finished, but there is no chance it will be
rejected at this point.

Since the namespace token RFC is passing, and I have seen the simplicity of
the new parser rules, my opinion has changed to keep pushing for #[] and I
accept the @@ outcome.

2. The phpcs argument also does not convince me.

Summed up it is essentially that a current version of phpcs does not
support parsing @@ or <<>> yet and incorrectly changes code using them,
however for #[] it does nothing because it parses it as a comment. To me
this sounds like a bug in PHPCS. This argument also breaks down completely
on multi line attributes.

Why should we even expect PHPCS to support an unreleased version? If
someone uses PHP 8 code, why do we assume they keep using an old version of
phpcs that does not support PHP 8 yet?

3. We already established that the syntax question is extremely
contentious, and I was getting tons of messages on it on Twitter, Reddit,
Email et al during the initial Attributes RFC. So of course people would be
against @@ (as I am myself), however it had a majority in votes.

For me putting these subjective opinions into the RFC makes the case for
overturning less convincing, because it makes the argument that overturning
a valid democratic vote is somehow OK if you are loud.

The only reason why we change this outcome must be purely technical imho.

4. You cannot write a regex to detect the end symbols for both #[] or <<>>,
because both end symbols are allowed *inside* the attribute syntax already,
so it's not easier to find occurrences with regexes with the other syntaxes:

#[Foo([1 => 2])]
<> 4)>>

Simple detection of attributes will always need to grep only for the start
token, and both @@ and #[ are equally unique to find here.

5. For readability an end token would be nicer (which is why i prefer #[]).
But this information was already known during the first vote on the syntax
and rejected by majority.

6. An end token might indeed allow extending attributes with new stuff, but
nobody has brought up this use-case before. No other language has
additional attribute keywords, why is this brought as a positive argument,
when the choice of syntax no other language uses is brought up as a
negative point later?

7. Future potential parsing problems are brought forward for @@, but #
being a comment token makes it likely that #[] will also cause problems.
Tyson has a few examples in his email to this thread.

Other confusing things you can do with #[] for example:

#[Foo( 1 # 1 ] bar
)]
function foo () { }

Which is #[Foo(1)] without comments and line breaks.

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[tyson andre]

Hi internals,

For #[, my main objection is the various ways this can change the lexing in a 
way that is impractical to (efficiently) backfill,
and that the proposed patch doesn't address the fact that the syntax may change 
the syntax of php 7 code in unexpected ways. 

This syntax would help phpcs with easy examples **in the short term**, when 
attributes are on a single line,
but would make more complicated refactorings buggy and error-prone unless 
phpcbf was run in the same major version.
When attributes span multiple lines, the lexing is completely different for 
`#[]`.
For example, the below syntax would yield false in php 7, but a generator in 
php 8.
(There's precedent at least - the lexing of heredocs changed in php 7.3 or 7.4)

```
// Aside: This code snippet seems to have an assert failure in the lexer with 
the patch in the RFC
// Zend/zend_compile.c:1794: zendlex: Assertion `!(executor_globals.exception) 
|| ret == T_ERROR' failed.
function generator() {
    yield #[MyCustomAttribute('
        false;
        // ']function() {};
}
```

And another example which would cause problems for phpcs in php 7 - the comment 
syntax can cause code to be treated as inline html instead of php tokens.

```
https://some-website/reason?>')]
function main() {}
const APP_SECRET = 'app-secret';
echo "Test\n";
```

I'd posted another example in https://externals.io/message/01#33

One way I'd thought of to avoid this ambiguity would be to assert in PHP 8.0 
with an E_COMPILE_ERROR (or E_COMPILE_WARNING) that:
1. All tokens of the #[...] annotation are on the same line
2. No non-whitespace token follows the ] on the same line.
It may be permissible to allow other `//` comments or multiple attributes 
after it on the same line, though.
3. No `?>` substrings within the rest of the line after #[, maybe

Although I'm not sure if others are actually concerned about this ambiguity and 
these are really artificial examples for code.

As for `<<`, I'm assuming people may have meant `yield <> function() {};`,
but `yield` already has a precedence and didn't have issues - otherwise 
`yield+2;`  could be adding 2 to the result of a yield.
(It's unambiguously `yield(+2);` right now).
I forget how it'd be parsed, but it wouldn't be ambiguous.

As for `@@`, all of its known issues seem to have been resolved,
and there is still the potential for future issues, but I still prefer it over 
the `#[` implementation in that patch.

P.S. I'd like to note that
1. A lot more discussion has occurred since the initial vote.
2. Since `@@` was obviously passing at the time, fewer voters would put much 
thought into detailed tradeoffs of `#[`
3. I haven't seen those specific drawbacks to `#[` of potentially significantly 
changing lexing (not just losing tokens) mentioned,
   but the shorter attributes syntax RFC did seem to mention params were 
commented out.

One idea I'd have on voting would be to have the exact same 3-way vote, again, 
and pick the attribute syntax with the same ranked choice procedure.
I assume proponents of `#[` would have similar objections if an RFC with a 
two-way vote for  `<<>>` and `@@` was started first.

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Mark Randall]

On 28/07/2020 22:55, Theodore Brown wrote:

I appreciate the examples. I think there are good reasons not to
implement these kind of extensions, at least in this form. I'll reply
to each example below.



The problem is your argument comes from a position of... because you 
don't like those examples, we shouldn't make accomodation for them or 
anything like them in future.


Adopting such extensions is a matter for a future RFC, and not for 
preemptively throwing a spanner in the works.


Mark Randall

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, July 28, 2020 at 2:38 PM Mark Randall  wrote:

> On 28/07/2020 18:57, Theodore Brown wrote:
> >> Having a closing ] makes it easier to extend Attributes with more syntax
> >
> > This might be a good argument if there were actually a need to extend
> > attributes with more syntax. What other languages have found a need for
> > this? Even Rust doesn't allow additional syntax inside the brackets.
> 
> Just because they haven't, does not mean we won't. Unless there's a good
> reason to do otherwise, we should provide for future flexibility where
> possible.
> 
> I previously provided examples of ways in which we might want to extend
> the syntax.

Hi Mark,

I appreciate the examples. I think there are good reasons not to
implement these kind of extensions, at least in this form. I'll reply
to each example below.

> Most things in PHP allow some level of scope restriction, such as
> private or protected. One day we may want to extend annotations to
> include such a feature, such as a protected annotation that can only be
> accessed by the class itself or its descendants.
> 
> #[protected MyAttribute(xyz)]

Given that attributes are metadata, restricting their scope seems
rather pointless, and probably would only encourage their (mis)use
for things they aren't the right solution for. Isn't the whole point
of an attribute to be read by something outside the class? If the
metadata is only for the class itself, class constants with
appropriate visibility can be used instead.

> Attributes are not validated when they are encountered, this may be
> something that we wish to allow attributes to opt-in to in future.
> 
> #[checked MyAttribute(xyz])

I hope if we allow opting into such a feature it won't have to be so
verbose and won't require making checked a new reserved keyword. I
suppose the same thing could be accomplished with a distinct token,
for example:

@@!MyAttribute(xyz)

> In future we might want to offer APIs that return an array of all of the
> instances (moving the creation up from newInstance) and then tighten up
> the behvaiour for classes which do not exist (because they might belong
> to an optional package, such as debugging or code analysis). This might
> come in the form of something like:
> 
> #[optional MyAttribute(xyz)]

Existing attributes are already optional, though, so it's not clear
what value this would add. If we want some attributes to not be
optional, we could add a new syntax for checked attributes like the
previous example.

> Some of these might happen, none of these might happen, something
> completely different might happen.
> 
> What is clear is we've got to support Attributes for 20, 30 years, and
> we should leave the door open for easier and cleaner syntax additions if
> there's no compelling reason not to.

I'm not convinced this approach of additional keywords before an
attribute is the easiest or cleanest way to implement additions. It
seems like it could lead to more BC breaks and unnecessary verbosity
if it encourages adding new keywords. And as you point out, whether
any such additions happen is completely hypothetical right now.

In the present what we do know is that #[] is a bigger BC break than
@@, and that other languages haven't had a need for such syntax
additions in the many years that attributes have been around.

Best regards,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Rowan Tommins]

On 28/07/2020 19:22, Niklas Keller wrote:


Do we handle 1XX responses, yet? 
https://tools.ietf.org/html/rfc7231#section-6.2



Yes, as of this patch a few years back: 
https://github.com/php/php-src/pull/2175/files



This is what implementations should do, see 
https://tools.ietf.org/html/rfc7230#section-2.6



I guess that's part of the "generous in what you accept" philosophy, 
since it makes no sense for a server to send a response chunked if the 
client didn't advertise 1.1 capabilities.




That section also says we should send 1.1, as we support it.


Indeed, as far as I have been able to tell, the client code now complies 
with the spec for HTTP 1.1, although I struggled to find a list of 
minimum capabilities.



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Peter Cowburn]

(Top posting because... sue me.)

I hereby propose to use @[] syntax for attributes.

No need to vote; it's clearly the best, nay only, real option.

Make it so.

P.S. Sorry for suggesting @@ earlier, I've no idea what I was thinking.
Creating new syntax is HARD!
P.P.S. <3

On Tue, 28 Jul 2020 at 20:59, Marcio Almada  wrote:

> Hi,
>
> >
> > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown 
> > wrote:
> >
> > >
> > > Hi Joe,
> > >
> > > From the perspective of looks alone I don't care much one way or the
> > > other between @@ and #[]. However, I don't find the arguments for #[]
> > > in this RFC very compelling, and it ignores some of the other downsides
> > > of #[] compared to @@ that should be highlighted. Let's go through the
> > > arguments from the RFC:
> > >
> >
> > 
> >
> > Theodore, thanks for your comments, time, and work on the Shorter
> Attribute
> > Syntax RFC. I appreciate your feedback and I'm also of the mind where I
> > don't care based on looks alone. The RFC also notes the @@ issues have
> been
> > resolved by the RFC closing at the end of the month.
> >
> > My motivation for this RFC is based on 2 things:
> >
> > Firstly, the @@ syntax makes parsing harder (although not impossible) on
> > CLI tools such as PHPCS. Therefore IMHO internals should make the best
> > effort to avoid this when possible.
> >
> > Secondly, I'd like to see internals use this as a point in the future to
> > avoid this kind of issue where we need to vote on something yet again
> > instead of taking the runner up in a ranked-choice vote. Originally this
> > was my main motivation until I saw the issues raised by the PHPCS users.
> >
>
> Is this issue documented somewhere on github or on any other platform?
> I'd like to see the discussion and maybe participate in it.
>
> Thanks,
> Márcio
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Marcio Almada]

Hi,

>
> On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown 
> wrote:
>
> >
> > Hi Joe,
> >
> > From the perspective of looks alone I don't care much one way or the
> > other between @@ and #[]. However, I don't find the arguments for #[]
> > in this RFC very compelling, and it ignores some of the other downsides
> > of #[] compared to @@ that should be highlighted. Let's go through the
> > arguments from the RFC:
> >
>
> 
>
> Theodore, thanks for your comments, time, and work on the Shorter Attribute
> Syntax RFC. I appreciate your feedback and I'm also of the mind where I
> don't care based on looks alone. The RFC also notes the @@ issues have been
> resolved by the RFC closing at the end of the month.
>
> My motivation for this RFC is based on 2 things:
>
> Firstly, the @@ syntax makes parsing harder (although not impossible) on
> CLI tools such as PHPCS. Therefore IMHO internals should make the best
> effort to avoid this when possible.
>
> Secondly, I'd like to see internals use this as a point in the future to
> avoid this kind of issue where we need to vote on something yet again
> instead of taking the runner up in a ranked-choice vote. Originally this
> was my main motivation until I saw the issues raised by the PHPCS users.
>

Is this issue documented somewhere on github or on any other platform?
I'd like to see the discussion and maybe participate in it.

Thanks,
Márcio

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Joe Ferguson]

On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown 
wrote:

>
> Hi Joe,
>
> From the perspective of looks alone I don't care much one way or the
> other between @@ and #[]. However, I don't find the arguments for #[]
> in this RFC very compelling, and it ignores some of the other downsides
> of #[] compared to @@ that should be highlighted. Let's go through the
> arguments from the RFC:
>



Theodore, thanks for your comments, time, and work on the Shorter Attribute
Syntax RFC. I appreciate your feedback and I'm also of the mind where I
don't care based on looks alone. The RFC also notes the @@ issues have been
resolved by the RFC closing at the end of the month.

My motivation for this RFC is based on 2 things:

Firstly, the @@ syntax makes parsing harder (although not impossible) on
CLI tools such as PHPCS. Therefore IMHO internals should make the best
effort to avoid this when possible.

Secondly, I'd like to see internals use this as a point in the future to
avoid this kind of issue where we need to vote on something yet again
instead of taking the runner up in a ranked-choice vote. Originally this
was my main motivation until I saw the issues raised by the PHPCS users.

I don't want this to become an issue of "keep voting until we get the vote
we like" as Paul mentioned. This RFC is my attempt to set a precedent where
internals allows itself to be some measurement more autonomous than it
currently is today. And also to try to make the 8.0 upgrade process a bit
friendlier to our fiends writing userland code.

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

-- 
- Joe Ferguson
JoeFerguson.me
osmihelp.org

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Jul 28, 2020, at 14:15, Ben Ramsey  wrote:
> 
>> On Jul 28, 2020, at 14:10, Paul M. Jones  wrote:
>> 
>>> On Jul 28, 2020, at 14:07, Ben Ramsey  wrote:
>>> 
 On Jul 28, 2020, at 13:55, Paul M. Jones  wrote:
 
 Now, it may be that #[] or <<>> or something else actually is "better" in 
 some sense that cannot be articulated. But if there are no existing 
 technical hurdles to be overcome with the already-voted-on-and-accepted 
 solution of @@, what technically compelling reason can there be to revote?
>>> 
>>> 
>>> IMO, there is no compelling reason to revote other than the fact that we 
>>> have no process for what to do in this situation.
>> 
>> What "situation" is this, exactly? AFICT we have a working implementation 
>> using @@, with no technical hurdles to surmount. Or have I missed something 
>> that now prevents @@ from working per its RFC?
> 
> 
> The new RFC outlines reasons why `@@` is a sub-optimal choice.

And yet it was the one chosen by the voting process. (Silly voters, making 
sub-optimal choices!)

The rest of your message reveals what I thought was true: i.e., there are no 
currently-verified technical barriers to @@. To wit:


> * current parser conflict (which can be worked around)

AFAICT that pre-existing problem has been fixed, so this is a non-issue.


> * possibility for further (as of yet unknown) parsing issues

IOW, imaginary issues, aka FUD.


> * a closing ] makes it easier to extend Attributes with more syntax,  and at 
> the same time not be at the risk of running into parser conflicts

Maybe, maybe not. This has the strongest possibility of becoming a technical 
argument, but no competing implementation (with a comparative implementation 
using @@)  has been presented as an example. So as it stands now, this also is 
imaginary.


> * userland analysis tools have difficulties parsing `@@`

Though it does not seem insurmountable for those userland authors. Also, this 
is an interesting take: does Internals now defer to userland? If so, maybe it's 
time to open up voting more widely, so that the whole of userland can be 
represented more effectively here.

Again, I don't especially care if @@, <<>>, or #[], or something else makes it 
through. Annotations of some sort seem like a nice idea, and I think they'd be 
of benefit.

But if we are to make decisions by what is ostensibly a democratic process, we 
should stick to the voted decisions, instead of re-voting issues until the 
voters "get it right" according to some implicit and unstated criteria.  (If 
re-voting over and over is the plan, I've got some RFCs I might like to revisit 
as well.)


-- 
Paul M. Jones
pmjo...@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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Mark Randall]

On 28/07/2020 18:57, Theodore Brown wrote:

Having a closing ] makes it easier to extend Attributes with more syntax


This might be a good argument if there were actually a need to extend
attributes with more syntax. What other languages have found a need for
this? Even Rust doesn't allow additional syntax inside the brackets.


Just because they haven't, does not mean we won't. Unless there's a good 
reason to do otherwise, we should provide for future flexibility where 
possible.


I previously provided examples of ways in which we might want to extend 
the syntax.


Most things in PHP allow some level of scope restriction, such as 
private or protected. One day we may want to extend annotations to 
include such a feature, such as a protected annotation that can only be 
accessed by the class itself or its descendants.


#[protected MyAttribute(xyz)]


Attributes are not validated when they are encountered, this may be 
something that we wish to allow attributes to opt-in to in future.


#[checked MyAttribute(xyz])


In future we might want to offer APIs that return an array of all of the 
instances (moving the creation up from newInstance) and then tighten up 
the behvaiour for classes which do not exist (because they might belong 
to an optional package, such as debugging or code analysis). This might 
come in the form of something like:


#[optional MyAttribute(xyz)]


Some of these might happen, none of these might happen, something 
completely different might happen.


What is clear is we've got to support Attributes for 20, 30 years, and 
we should leave the door open for easier and cleaner syntax additions if 
there's no compelling reason not to.


--
Mark Randall

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Ben Ramsey]

> On Jul 28, 2020, at 14:10, Paul M. Jones  wrote:
> 
>> On Jul 28, 2020, at 14:07, Ben Ramsey  wrote:
>> 
>>> On Jul 28, 2020, at 13:55, Paul M. Jones  wrote:
>>> 
>>> Now, it may be that #[] or <<>> or something else actually is "better" in 
>>> some sense that cannot be articulated. But if there are no existing 
>>> technical hurdles to be overcome with the already-voted-on-and-accepted 
>>> solution of @@, what technically compelling reason can there be to revote?
>> 
>> 
>> IMO, there is no compelling reason to revote other than the fact that we 
>> have no process for what to do in this situation.
> 
> What "situation" is this, exactly? AFICT we have a working implementation 
> using @@, with no technical hurdles to surmount. Or have I missed something 
> that now prevents @@ from working per its RFC?


The new RFC outlines reasons why `@@` is a sub-optimal choice.

TL;DR:

* current parser conflict (which can be worked around)
* possibility for further (as of yet unknown) parsing issues
* a closing ] makes it easier to extend Attributes with more syntax,
  and at the same time not be at the risk of running into parser
  conflicts
* userland analysis tools have difficulties parsing `@@`


Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Jul 28, 2020, at 14:07, Ben Ramsey  wrote:
> 
>> On Jul 28, 2020, at 13:55, Paul M. Jones  wrote:
>> 
>> Now, it may be that #[] or <<>> or something else actually is "better" in 
>> some sense that cannot be articulated. But if there are no existing 
>> technical hurdles to be overcome with the already-voted-on-and-accepted 
>> solution of @@, what technically compelling reason can there be to revote?
> 
> 
> IMO, there is no compelling reason to revote other than the fact that we have 
> no process for what to do in this situation.

What "situation" is this, exactly? AFICT we have a working implementation using 
@@, with no technical hurdles to surmount. Or have I missed something that now 
prevents @@ from working per its RFC?


-- 
Paul M. Jones
pmjo...@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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Ben Ramsey]

> On Jul 28, 2020, at 13:55, Paul M. Jones  wrote:
> 
> Now, it may be that #[] or <<>> or something else actually is "better" in 
> some sense that cannot be articulated. But if there are no existing technical 
> hurdles to be overcome with the already-voted-on-and-accepted solution of @@, 
> what technically compelling reason can there be to revote?


IMO, there is no compelling reason to revote other than the fact that we have 
no process for what to do in this situation. However, given that we used 
ranked-choice voting in the last RFC, the logical choice (to me) seems to be: 
choose the runner-up in the event that the winner is disqualified.

So, if there are extenuating circumstances that result in `@@` being 
disqualified, we should automatically default to the runner-up in the 
ranked-choice outcome.

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Paul M. Jones]

Hi all,

> On Jul 28, 2020, at 12:57, Theodore Brown  wrote:
> 
>> On Tue, July 28, 2020 at 9:46 AM Joe Ferguson  wrote:
>> 
>> ...
>> 
>> Feedback to Derick's tweet 
>> (https://twitter.com/derickr/status/1285912223639130114)
>> were [sic] overwhelmingly positive
> 
> Are you sure? I took a look at the thread and it seems like the
> responses were pretty mixed.

Let's count. + is "change away from @@ to anything else", - is "stay with @@", 
? is hard-to-tell/weak/uncertain/they-all-suck.

Derick Rethans: ++
Rafael Dohms: +?
Alexander Berl: -?
Chris Emerson: --
Tamas Erdelyi: ??
Phili Weinke: ??
Trent: ++
Juriaan Ruitenberg: ++
Mehran: ++
Stephan Hochdorfer: ??
Cees-Jan Kiewiet: ??
Tom Witkowski: ++
Matiss: ++
Henry Paradiz: --
Saif: ??
Paul Redmond: ??
Marco Pivetta: ++
Simon Champion: ??
@eimihar: ??
Brent: +?
Graham Campbell: +?
Dmitri Goosens: ++
Sergej Kurakin: -?
Francis Lavoie: ??
Michael Moravec: ??
John Hunt: ??
Lars Moelleken: ??
Michal Brzuchalski: -?
Kyrre: ??
Steve MacDougall: ++
Agustin Gomes: ??
Mike Rockett: ++
Matias Navarro: ++
Marisa Clardy: ++
Warp Speed: --
WJB: +?
Martijn Minnis: --
Dennis de Best: ??
Damo: ??
SOFTonSOFA: +?
Ashish K. Poudel: +?
Bastien Remy: ??
Matiss: +?
Thierry D.: +?
Ihor Vorotnov: ??
Hugo Alliaume: ??
Juan Millan: +?
Olbaum: +?
Steve Baumann: ??
James Mallison: ??
Marco Deleu: ??
TheGenuinenessSheriff: ++
Golgote: ??

++: 13 definitely prefer changing to something other than @@ (though not 
necessarily #[])
+?: 10 probably prefer changing to something other than @@ (though not 
necessarily #[])
??: 23 hard-to-tell/weak/uncertain/they-all-suck
-?: 3 probably prefer to keep @@
--: 4 definitely prefer to keep @@

So, the majority of Twitter respondents in that thread appear to be against @@, 
and in favor of "something else" (24 to 7).

Having pointed all that out, I note that Twitter is not the voting mechanism 
here. Further, I opine that "voting repeatedly until the voters get it 'right' 
and then calling the matter settled for all time" is not how decision-by-voting 
is supposed to work.

Now, it may be that #[] or <<>> or something else actually is "better" in some 
sense that cannot be articulated. But if there are no existing technical 
hurdles to be overcome with the already-voted-on-and-accepted solution of @@, 
what technically compelling reason can there be to revote?


-- 
Paul M. Jones
pmjo...@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

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Niklas Keller]

Hey all,

>
> > Given that it's a very small change, the RFC is probably not necessary,
> in
> > which case it's not too late, however I'd like some clarification about
> > what this actually offers over defaulting to 1.0.
>

One thing it offers is detecting truncated responses. Servers will often
respond without transfer-encoding: chunked / content-length for an HTTP/1.0
request, which leaves connection closure as only indication where the
response ends.

As we progress to HTTP/3 already, newer implementations might not implement
1.0 at all. If we're compatible with 1.1 already, there's no reason IMO not
to advertise and use its features.

That's a very reasonable question. The way I see it is this:
>
> The risk of advertising 1.0 by default is that some software will have been
> programmed to outright refuse that protocol version. I don't know of any
> recent examples, but this bug report from 2007 was for a SOAP endpoint that
> returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069
> Notably, Dmitry's patch for that bug made sure the protocol context option
> is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as
> of PHP 5.3.
>
> The risk of advertising 1.1 by default is that some software will respond
> with a more complex response, and trigger some bug in our response parsing.
> This was previously the case with detecting "Transfer-Encoding: chunked"
> headers, for instance. By advertising 1.0, we may be benefitting from
> servers "downgrading" their response.
>

Do we handle 1XX responses, yet?
https://tools.ietf.org/html/rfc7231#section-6.2


> In practice, a large amount of software appears to do neither, and simply
> replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk
> about "advertising" versions - in practice, the code is always acting as an
> HTTP/1.1 client, e.g. sending "Connection: Close", and listening for
> Transfer-Encoding, because it's increasingly rare for a server to actually
> honour the 1.0 spec.
>

This is what implementations should do, see
https://tools.ietf.org/html/rfc7230#section-2.6

That section also says we should send 1.1, as we support it.

Best,
Niklas


> My main motivation for the change is that if someone was writing the
> feature today, I don't think it would occur to them to default to 1.0, and
> I think _new_ users would be less surprised at needing to opt into 1.0 than
> into 1.1.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, July 28, 2020 at 9:46 AM Joe Ferguson  wrote:

> Hello Internals,
> 
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for Shorter
> Attribute Syntax.
> 
> An important part of the research that went into this proposal demonstrates
> how "@@" will make handling attributes more difficult for PHP_CodeSniffer
> (and similar tools) and shows how the alternative "#[]" syntax is more
> friendly for these tools.
> 
> You can find the RFC
> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
> answer any questions as best I can.

Hi Joe,

>From the perspective of looks alone I don't care much one way or the
other between @@ and #[]. However, I don't find the arguments for #[]
in this RFC very compelling, and it ignores some of the other downsides
of #[] compared to @@ that should be highlighted. Let's go through the
arguments from the RFC:

> It [@@] currently causes a parser conflict

This isn't true now that namespaced names are treated as tokens. The
@@ implementation has been merged into php-src and there is no parser
conflict.

> Various luminaires [sic] consider @@ a joke

Who does this refer to? A random Reddit user?

> Feedback to Derick's tweet 
> (https://twitter.com/derickr/status/1285912223639130114)
> were [sic] overwhelmingly positive

Are you sure? I took a look at the thread and it seems like the
responses were pretty mixed. Some people expressed support for #[],
but almost as many were happier with the @@ syntax. If anything the
majority of responses were neutral or expressing dislike for all the
syntax options.

> It has the distinct possibility to cause further parsing issues

Like what? How is it any more likely to cause parsing issues than the
@ syntax used by the majority of other C family languages?

> Having a closing ] makes it easier to extend Attributes with more syntax

This might be a good argument if there were actually a need to extend
attributes with more syntax. What other languages have found a need for
this? Even Rust doesn't allow additional syntax inside the brackets.

> There is no “end symbol” to make finding occurrences easier,
> including by reading or using regular expressions.

Can you provide an example? When reading code I personally don't find
the ending bracket very helpful - my brain tends to parse it as the
end of an array, not the end of an attribute. Even when using a regex
to search code, the ending bracket doesn't seem very helpful since
arrays can also be passed as attribute arguments. For example, to
match this attribute the regex for @@ is actually simpler than the
one for #[]:

```php
# regex: /@@\w+\(.+\)/
@@Attr([1, 2])

# vs.

# regex: /#\[\w+\(.+\)\]/
#[Attr([1, 2])]
```

> A syntax with a closing demarcation is much easier to back fill with
> tools such as PHPCS.

I'm not sure I understand this. What does it mean to "back fill" a
syntax with PHPCS, and what does a closing demarcation have to do with
it? As a user, I'd expect to have to update PHPCS to work with PHP 8
code - doesn't it have to be updated anyway to correctly support the
syntax for named arguments, union types, the nullsafe operator, match
expression, etc.?

And from a perspective of compatibility with existing tools, couldn't
@@ be considered superior since people can use it in code examples
on a blog without the syntax highlighter treating it as a comment?

> It is a syntax no other language uses.

Rust chose to use #[] even though it wasn't used by any other language.
Does that make it a bad fit for Rust? No. But just because Rust uses
a syntax also doesn't mean it's a good fit for PHP.

@@ fits well with PHP since there is virtually no BC break, and the
syntax is close to the @annotation syntax currently used in docblocks,
so it's easily recognizable for what it is. On the other hand, #[]
would be a larger BC break and can easily be confused for a comment.

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Sara Golemon]

On Tue, Jul 28, 2020 at 3:52 AM Rowan Tommins 
wrote:

> The risk of advertising 1.0 by default is that some software will have been
> programmed to outright refuse that protocol version. I don't know of any
> recent examples, but this bug report from 2007 was for a SOAP endpoint that
> returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069
> Notably, Dmitry's patch for that bug made sure the protocol context option
> is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as
> of PHP 5.3.
>
> The risk of advertising 1.1 by default is that some software will respond
> with a more complex response, and trigger some bug in our response parsing.
> This was previously the case with detecting "Transfer-Encoding: chunked"
> headers, for instance. By advertising 1.0, we may be benefitting from
> servers "downgrading" their response.
>
> In practice, a large amount of software appears to do neither, and simply
> replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk
> about "advertising" versions - in practice, the code is always acting as an
> HTTP/1.1 client, e.g. sending "Connection: Close", and listening for
> Transfer-Encoding, because it's increasingly rare for a server to actually
> honour the 1.0 spec.
>
> The "servers have a bad habit of ignoring this anyway" argument is
probably true, but it sort of takes the wind out of BOTH of the other two
points. :)

I'm not going to object to merging it, the worst case scenario is that a
few app developers will learn the protocol version option exists and have
to set "1.0" manually.  Even that is a low probability.  Probably better in
the long-term to inch our way forward and advertise a protocol that was
introduced... checks notes... 21 years ago.

-Sara

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Sebastian Bergmann]

Am 28.07.2020 um 17:50 schrieb Derick Rethans:

This is an excellent RFC highlighting the important deficiencies of the
@@ syntax.

I hope you will all read this and also conclude that we can still pick
this better syntax.

Remember that it is not only about how it looks. It is much more
important that it is functional and causes the least amount of friction
in the community.


Hear, hear.

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Derick Rethans]

On Tue, 28 Jul 2020, Joe Ferguson wrote:

> I've been working with Derick Rethans and others (thanks all!) on a 
> Shorter Attribute Syntax Change RFC which outlines reasons why the 
> "#[]" syntax would be preferred over the currently agreed upon "@@" 
> syntax for Shorter Attribute Syntax.

This is an excellent RFC highlighting the important deficiencies of the 
@@ syntax.

I hope you will all read this and also conclude that we can still pick 
this better syntax.

Remember that it is not only about how it looks. It is much more 
important that it is functional and causes the least amount of friction 
in the community.

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Ben Ramsey]

> On Jul 28, 2020, at 10:13, Côme Chilliet  
> wrote:
> 
> Le Tue, 28 Jul 2020 09:46:38 -0500,
> Joe Ferguson  a écrit :
> 
>> Hello Internals,
>> 
>> I've been working with Derick Rethans and others (thanks all!) on a Shorter
>> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
>> would be preferred over the currently agreed upon "@@" syntax for Shorter
>> Attribute Syntax.
>> 
>> An important part of the research that went into this proposal demonstrates
>> how "@@" will make handling attributes more difficult for PHP_CodeSniffer
>> (and similar tools) and shows how the alternative "#[]" syntax is more
>> friendly for these tools.
>> 
>> You can find the RFC
>> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
>> answer any questions as best I can.
>> 
> 
> The text uses « instead of <<, it’s confusing.
> 
> It should be made clearer what #[ ] has over << >>, which does not cause any 
> BC
> break.
> 
> Côme


I don’t know that it’s valuable to spend time discussing advantages
over `<< >>`. Isn’t it clear from the previous RFC[^1] that `@@` and
`#[ ]` both won out over `<< >>`?

Cheers,
Ben


[^1]: https://wiki.php.net/rfc/shorter_attribute_syntax


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Côme Chilliet]

Le Tue, 28 Jul 2020 09:46:38 -0500,
Joe Ferguson  a écrit :

> Hello Internals,
> 
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for Shorter
> Attribute Syntax.
> 
> An important part of the research that went into this proposal demonstrates
> how "@@" will make handling attributes more difficult for PHP_CodeSniffer
> (and similar tools) and shows how the alternative "#[]" syntax is more
> friendly for these tools.
> 
> You can find the RFC
> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
> answer any questions as best I can.
> 

The text uses « instead of <<, it’s confusing.

It should be made clearer what #[ ] has over << >>, which does not cause any BC
 break.

Côme

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

Re: [PHP-DEV] Registration on wiki

[Josh Bruce]

Also be sure to add the mailing list address as the final email - the one you 
want to send emails to.

This is the part I missed and received the same error.

I don’t know if this counts as the captcha but the label is somewhat confusing, 
which is perfect if it’s meant to be the captcha Kalle mentions. Also not sure 
if the question changes - it’s always been the same for me.

Would give credit to the person who pointed this out earlier to someone else 
that I happened to see and try, but I don’t remember who it was.

Cheers,
Josh


> On Jul 28, 2020, at 12:54 AM, [ ]  wrote:
> 
> Thank you, I will do that.
> 
> On Tue, Jul 28, 2020 at 8:46 AM Kalle Sommer Nielsen  wrote:
> 
>> 
>> 
>> tir. 28. jul. 2020 kl. 08.39 skrev [ ] :
>> 
>>> When I try to register on https://wiki.php.net/?do=register ,
>>> 
>>> Such error is generated: "That wasn't the answer we were expecting".
>> 
>> 
>> 
>> This means you failed the captcha on the registration form, please read
>> the page in detail and it should be a walk in the park.
>> 
>> -K
>> 
>>> --
>> regards,
>> 
>> Kalle Sommer Nielsen
>> ka...@php.net
>> 

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

[PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Joe Ferguson]

Hello Internals,

I've been working with Derick Rethans and others (thanks all!) on a Shorter
Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
would be preferred over the currently agreed upon "@@" syntax for Shorter
Attribute Syntax.

An important part of the research that went into this proposal demonstrates
how "@@" will make handling attributes more difficult for PHP_CodeSniffer
(and similar tools) and shows how the alternative "#[]" syntax is more
friendly for these tools.

You can find the RFC
https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
answer any questions as best I can.

-- 
- Joe Ferguson
JoeFerguson.me
osmihelp.org

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Joe Ferguson]

On 7/28/2020 08:31, Nikita Popov wrote:

However, with my RM hat on, I need to feel like we're as sure as we can be

about this syntax before it's public.
I'm willing to extend an additional period (up to the tagging of beta3, in
just under six weeks) for a re-vote on the syntax as changing that will be
less violent of a change than merging the entire implementation after
branching.


So, does anyone plan to pursue this?

Nikita



Yes. I'll have an RFC to announce shortly. Waiting on one last review 
before sharing here.

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Nikita Popov]

On Thu, Jul 23, 2020 at 6:46 PM Sara Golemon  wrote:

> On Thu, Jul 23, 2020 at 10:19 AM Sara Golemon  wrote:
>
> > If that's the case, then the solution still seems obvious: Defer
> > attributes to 8.1.
> >
> > After some discussion off list, including Nikita (who is probably closer
> to this "problem" than any of the rest of us), I think the best way forward
> at the moment is to proceed with the voted on action: Merge attributes
> using @@ syntax prior to the feature freeze date.
>

Done.

However, with my RM hat on, I need to feel like we're as sure as we can be
> about this syntax before it's public.
> I'm willing to extend an additional period (up to the tagging of beta3, in
> just under six weeks) for a re-vote on the syntax as changing that will be
> less violent of a change than merging the entire implementation after
> branching.
>

So, does anyone plan to pursue this?

Nikita

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Björn Larsson]

Hi Rowan,

Den 2020-07-28 kl. 10:52, skrev Rowan Tommins:


Hi Sara,

On Tue, 28 Jul 2020 at 00:24, Sara Golemon  wrote:


Given that it's a very small change, the RFC is probably not necessary, in
which case it's not too late, however I'd like some clarification about
what this actually offers over defaulting to 1.0.



That's a very reasonable question. The way I see it is this:

The risk of advertising 1.0 by default is that some software will have been
programmed to outright refuse that protocol version. I don't know of any
recent examples, but this bug report from 2007 was for a SOAP endpoint that
returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069
Notably, Dmitry's patch for that bug made sure the protocol context option
is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as
of PHP 5.3.

The risk of advertising 1.1 by default is that some software will respond
with a more complex response, and trigger some bug in our response parsing.
This was previously the case with detecting "Transfer-Encoding: chunked"
headers, for instance. By advertising 1.0, we may be benefitting from
servers "downgrading" their response.

In practice, a large amount of software appears to do neither, and simply
replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk
about "advertising" versions - in practice, the code is always acting as an
HTTP/1.1 client, e.g. sending "Connection: Close", and listening for
Transfer-Encoding, because it's increasingly rare for a server to actually
honour the 1.0 spec.

My main motivation for the change is that if someone was writing the
feature today, I don't think it would occur to them to default to 1.0, and
I think _new_ users would be less surprised at needing to opt into 1.0 than
into 1.1.

Regards,



I think there is also a consistency argument to make here. If the code
behaves like HTTP 1.1, I think it also should advertise it as such. So go
for it!

Regards //Björn L

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

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Rowan Tommins]

On Tue, 28 Jul 2020 at 10:13, Eliot Lear  wrote:

> I think this is ok for a client.  I'd feel differently about servers.
> There may be other subtle changes between 1.0 and 1.1.  Have you
> reviewed those?
>


I did my best; see previous mails in this thread for my analysis. It's
surprisingly hard to find a succinct summary of what _requirements_ are
changed between specs, rather than just new features.

As I say, though, that will only affect us if a server is strictly
implementing both versions of the spec and behaving differently because we
send HTTP/1.0. The fact that various HTTP 1.1 features are enabled in our
client code by default suggests that is frequently not the case.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Rowan Tommins]

Hi Sara,

On Tue, 28 Jul 2020 at 00:24, Sara Golemon  wrote:

>
> Given that it's a very small change, the RFC is probably not necessary, in
> which case it's not too late, however I'd like some clarification about
> what this actually offers over defaulting to 1.0.
>


That's a very reasonable question. The way I see it is this:

The risk of advertising 1.0 by default is that some software will have been
programmed to outright refuse that protocol version. I don't know of any
recent examples, but this bug report from 2007 was for a SOAP endpoint that
returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069
Notably, Dmitry's patch for that bug made sure the protocol context option
is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as
of PHP 5.3.

The risk of advertising 1.1 by default is that some software will respond
with a more complex response, and trigger some bug in our response parsing.
This was previously the case with detecting "Transfer-Encoding: chunked"
headers, for instance. By advertising 1.0, we may be benefitting from
servers "downgrading" their response.

In practice, a large amount of software appears to do neither, and simply
replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk
about "advertising" versions - in practice, the code is always acting as an
HTTP/1.1 client, e.g. sending "Connection: Close", and listening for
Transfer-Encoding, because it's increasingly rare for a server to actually
honour the 1.0 spec.

My main motivation for the change is that if someone was writing the
feature today, I don't think it would occur to them to default to 1.0, and
I think _new_ users would be less surprised at needing to opt into 1.0 than
into 1.1.

Regards,
-- 
Rowan Tommins
[IMSoP]