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

[Theodore Brown]

On Thu, Aug 6, 2020 at 12:30 PM Benas IML  wrote:

> Hey Theodore,
>
> On Thu, Aug 6, 2020, 8:05 PM Theodore Brown  wrote:
> 
> > While none of our syntax options are perfect, I believe @@ has the
> > best long-term tradeoffs because:
> >
> > - It doesn't break useful syntax
> 
> Fair enough.
> 
> > - It is equally or more concise than grouped attributes without
> > adding complexity to the parser/compiler
> 
> Are we really going to debate that ~30 lines of code add complexity?

Hi Benas,

I don't know how many lines of code it will be, since an
implementation for it has never been finished. The patch currently
linked in the RFC does not implement it.

Even if we assume the implementation is only about 30 lines, it's
still extra complexity that I don't understand the benefit of. I
sincerely would like to know what advantage there is of grouped
attributes over the `@@` syntax.

- It is equally or more verbose than `@@` in real-world use cases
- Adding or removing a second attribute with grouping can require
modifying multiple lines, adding unnecessary noise to diffs:

  @@SomeAttribute("value")
  @@AnotherAttribute("value") # can be added/removed independently
  function foo() {}

  # vs.

  @[SomeAttribute("value")] # changes to:

  @[
  SomeAttribute("value"),
  AnotherAttribute("value"), # not added/removed independently
  ]
  function foo() {}

- How much more added complexity will the grouped syntax require if
we add nested attributes in the future? At the least it will have to
be special-cased in some way, either to disallow grouping for nested
attributes or to treat the grouped syntax the same as an array.

`@@` avoids the need for additional complexity, special cased syntax,
and having to modify extra lines when adding/removing separate
attributes.

> > - It is conceptually closest to the docblock syntax the PHP
> > community is familiar with
> 
> Well, if `@@` is similar to `@` (to me it isn't), we can say that
> `@[]` is also similar to `@`.

I would agree that `@[]` is more similar than `#[]` is. But arguably
`@@` is still the closest since docblock annotations don't require
being wrapped in array brackets.

> > - It is aligned with the attribute semantics of the majority of C
> > family languages
>
> In what way `#[]` or `@[]` aren't?

The majority of C family languages use `@Attr` without an extra end
symbol. This makes sense since attributes are simply metadata
modifying the declaration that follows them, similar to visibility
and type declarations.

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

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

[Benas IML]

Hey Theodore,

On Thu, Aug 6, 2020, 8:05 PM Theodore Brown  wrote:

> On Thu, Aug 6, 2020 at 5:24 AM Benas IML 
> wrote:
>
> > On Thu, 6 Aug 2020 at 11:45, Rowan Tommins 
> wrote:
> >
> > > On Thu, 6 Aug 2020 at 09:12, Benas IML 
> wrote:
> > >
> > > > But by sacrificing a few very old codebases (that still use `#` not
> `//`)
> > >
> > > Do you have some basis for # only being used by "very old" codebases?
> As
> > > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> > >
> > > I agree that it is probably rarer than //... and /*...*/ but let's
> avoid
> > > unnecessary hyperbole.
>
> > A grep search was done by someone in the mailing list in the original
> > `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> > to be a huge BC or not.
> >
> > Just about all of the matches were either from old codebases or from
> > old PHP 3-5 Metasploit exploits, which are about 5-15 years old.
>
> Hi Benas,
>
> You can look at the grep search here:
> https://grep.app/search?q=%23%5B[lang][0]=PHP
>
> The first BC break in the results is from an automated pentest
> framework repository which was last updated four days ago. So it
> seems like this is still code that is being used.
>

I work myself in the cybersecurity industry and I can tell you 100% that
the automated pentesting tool you're referring to isn't using any of that
`#[` code actively. In fact, over 80% of the code/exploits stored in that
repository don't work with new software/language versions.

That's the whole point - there are hundreds of scripts in numerous
different languages designed for exploiting only specific subset of
software designed for only specific versions of PHP/other languages.

By 5-15 years, I meant the exploits themselves.

Even the current Psalm static analysis tests use # to comment out an
> array:
> https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453
>
> Not that these individual examples are a big problem, they simply
> illustrate that hash comments are still used in current projects,
> sometimes in ways that the #[] attribute syntax would break.
>

...and that can be fixed within 5 seconds.

`#` comments were even deprecated in PHP's ini files in 5.6.


> When it comes to the @[] alternative, it's harder to grep for actual
> usages, since this string is used in virtually every email validation
> regex. In any case, code like @[foo(), bar()] would no longer work
> without putting a space between the error suppression operator and
> array (which frankly looks pretty confusing):
>
> $x =
> @ [Foo()]; // an array assignment with suppressed warnings
> @[Jit()] // an attribute
> function bar() {}
>

Same goes without saying with `@@` where `@@` means attributes and `@ @`
means double error suppression. Albeit, that is not useful.


> If there were some important language improvement that depended on
> breaking these syntaxes, maybe it would be justified. But so far I
> haven't seen such a justification.
>
> > We are playing probabilities here but at the moment, no one has said
> > any substantial argument why `@@` is better and thus, `@[...]` seems
> > like a better option in the long term.
>
> While none of our syntax options are perfect, I believe @@ has the best
> long-term tradeoffs because:
>
> - It doesn't break useful syntax
>

Fair enough.

- It is equally or more concise than grouped attributes without adding
> complexity to the parser/compiler
>

Are we really going to debate that ~30 lines of code add complexity?

- It offers a clean, simple way to support nested attributes in the
> future if we so desire
>

I'm sorry if I'm not following the conversation but what is blocking that
in `#[]`/`@[]`.

- It is conceptually closest to the docblock syntax the PHP community
> is familiar with
>

Well, if `@@` is similar to `@` (to me it isn't), we can say that `@[]` is
also similar to `@`.

- It is aligned with the attribute semantics of the majority of C
> family languages
>

In what way `#[]` or `@[]` aren't?


> Best regards,
> Theodore


Best regards,
Benas

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

[Theodore Brown]

On Thu, Aug 6, 2020 at 5:24 AM Benas IML  wrote:

> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins  wrote:
> 
> > On Thu, 6 Aug 2020 at 09:12, Benas IML  wrote:
> >
> > > But by sacrificing a few very old codebases (that still use `#` not `//`)
> >
> > Do you have some basis for # only being used by "very old" codebases? As
> > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> >
> > I agree that it is probably rarer than //... and /*...*/ but let's avoid
> > unnecessary hyperbole.

> A grep search was done by someone in the mailing list in the original
> `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> to be a huge BC or not.
> 
> Just about all of the matches were either from old codebases or from
> old PHP 3-5 Metasploit exploits, which are about 5-15 years old.

Hi Benas,

You can look at the grep search here: 
https://grep.app/search?q=%23%5B[lang][0]=PHP

The first BC break in the results is from an automated pentest
framework repository which was last updated four days ago. So it
seems like this is still code that is being used.

Even the current Psalm static analysis tests use # to comment out an
array: 
https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453

Not that these individual examples are a big problem, they simply
illustrate that hash comments are still used in current projects,
sometimes in ways that the #[] attribute syntax would break.

When it comes to the @[] alternative, it's harder to grep for actual
usages, since this string is used in virtually every email validation
regex. In any case, code like @[foo(), bar()] would no longer work
without putting a space between the error suppression operator and
array (which frankly looks pretty confusing):

$x =
@ [Foo()]; // an array assignment with suppressed warnings
@[Jit()] // an attribute
function bar() {}

If there were some important language improvement that depended on
breaking these syntaxes, maybe it would be justified. But so far I
haven't seen such a justification.

> We are playing probabilities here but at the moment, no one has said
> any substantial argument why `@@` is better and thus, `@[...]` seems
> like a better option in the long term.

While none of our syntax options are perfect, I believe @@ has the best
long-term tradeoffs because:

- It doesn't break useful syntax
- It is equally or more concise than grouped attributes without adding
complexity to the parser/compiler
- It offers a clean, simple way to support nested attributes in the
future if we so desire
- It is conceptually closest to the docblock syntax the PHP community
is familiar with
- It is aligned with the attribute semantics of the majority of C
family languages

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

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

[Claude Pache]

> Le 6 août 2020 à 10:11, Benas IML  a écrit :
> 
> Ending delimiter MAY help us in the future.
> 
> I really, really hate all of those arguments stating "that we should care
> only about the present, not the future" and that even though
> `#[...]`/`@[...]` might bring benefits in the future, we should still
> choose `@@`".
> 
> This shows clearly that some people are basing their views on subjective
> reasons rather than being objective.
> 
> As far as this discussion is going, I see pro-`@@` people just saying
> "Arghhh, let's keep @@, it doesn't bring any benefits that other syntaxes
> do but we don't need them anyways, let's not speculate future".
> 
> It's like saying you can either go through door A and get a free car or
> through door B and get the same car and **maybe**, even an additional
> 1,000$.
> 
> We are playing probabilities here but at the moment, no one has said any
> substantial argument why `@@` is better and thus, `@[...]` seems like a
> better option in the long term.
> 


Note that, in a hypothetical future where the absence of delimiters would lead 
to (perceive or real) ambiguity, it will always possible to add optional ones, 
as in: `@@simple("thing")` and `@@{very("complex") thing}`.

—Claude

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

[Benas IML]

A grep search was done by someone in the mailing list in the original
`<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
to be a huge BC or not.

Just about all of the matches were either from old codebases or from
old PHP 3-5 Metasploit exploits, which are about 5-15 years old.

Best regards,
Benas

P.S: I accidentally sent this to Rowan only, so forwarding this to the
mailing list as well.

On Thu, 6 Aug 2020 at 11:45, Rowan Tommins  wrote:
>
> On Thu, 6 Aug 2020 at 09:12, Benas IML  wrote:
>
> >
> > But by sacrificing a few very old codebases (that still use `#` not `//`)
> >
>
>
> Do you have some basis for # only being used by "very old" codebases? As
> far as I'm aware, it's not deprecated, and while the PEAR style guide
> listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
>
> I agree that it is probably rarer than //... and /*...*/ but let's avoid
> unnecessary hyperbole.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]

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

[PHP-DEV] PHP 8.0.0beta1 is ready for testing

[Gabriel Caruso]

PHP 8.0.0beta1 has just been released and can be
downloaded from https://downloads.php.net/~carusogabriel

Or use the git tag: `php-8.0.0beta1`

Windows binaries are available at https://windows.php.net/qa

Please test it carefully, and report any bugs in
the bug system: https://bugs.php.net

8.0.0beta2 should be expected in 2 weeks, i.e. on Aug 20, 2020.

Hash values and PGP signatures can be found below or at
https://gist.github.com/carusogabriel/6e0b8b33ee4dd2da23002863af4de965

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso

PHP 8.0.0 Beta1 Manifest:

```
php-8.0.0beta1.tar.gz
SHA256 hash:
5c9f888b101e31540074b83c1c2b24771dab0f64c0ef1e3d217ade3306148d7c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8poLoWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj9okD/9ynWJ9vPF3ouv8Neq1laMcGpJW
p3vSJAmUT5lZWj+8HHDPkGkDx+eqpzV7GGgEYaHhsUcGxlRsM6HBZS/xA/zx8CqE
xLLJ/eqdSPaUVI5M9oKZdeKP+Tfl4zIeNnBy9HKIYnXYqRFiWpamGANtDhjsWlSr
dTTaazXvp5292iU3Sk+Lk+zXoWfR1JEP1oh2iu2A12T5j0jzXs1Gn2HCCK11mj0/
nNCEy1tp3ZNF3ZOlrzmePLS2rW7MtZVT+4PPUWmb7wcmLvTR27uzEKx+L0VbAOut
EypOPG9p+jokhB2TpwQHeE4IKFdeMk+2CD4aipQGeVmAFWuskX2gbfqhUGdRly2V
CTpYmT/E2Bgg5FX79hE2fsO+xverj4ofiBQ9DSo3v+r8h+d1ty+av5bM0FwlC7dv
KMNX0c+4Q76m8kBIXJRDZu3ViofFuRJo4/2QRWq8jCfm4pj2t2Ecld+SdzTLxBBy
dqE2GgzddkYpHxx0hdcl6aWtXyOxNWMS7z+Z4pQkuM5TuhRH+TG5U2l44HMoyxPW
eKrkZjeHvdqRinHva3u851nmQuAnvvRw0KeyolFteVGetvp5kse8DaThnIISDJJh
Jx1p9JVlxMFE707ZoM2SSf5Uxik2uTyph7HYym5q3IZOmaxL6bNN1TGfnKg6MGE3
xpCJRQ5EYq5b+5h83A==
=vo0v
-END PGP SIGNATURE-

php-8.0.0beta1.tar.bz2
SHA256 hash:
1f2101789aee0384ff6712bb11d1875c8361359ee780fb41b2f1e073916dc331
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8poLsWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj1m1EACgdg83GkHvaiHL5OdqCsmnAElc
F2xAEmzogBBa9cqYrM5/LMEPiezSeTUEgD6BJFUYRRWkVbSe1F+zxnpwe2V8SR7Y
tfY9oGJ03YVr+lIvdONzDBR8lIAltsF4PFLBk0SVRT8zsnyXY5hN0F/RXGotSp+N
EwOblFseKGIzsQ5hCSWiawgu+mUZUBA892mseZFi3j1KVTy6IxAsmvu4HCTybp1X
VSqKK9ktUIy8XFuTqTEzAnpoTfnnf7As4ANmtXDYrQ6PegtNlDiHIiuHHhIKmUc8
02HbdKlNDzdE08K4cFILmyJKVw184iE0nIJIcykB8y5QrF8jmgsmrvqqei+YpIoN
ufoMD5jnN931Fh3/mZMLrxXpt9+B2ml0n8UllEQxgzOf7Cfz58hQjvHl3aS17l77
cXtbB9Hb4S6XnAYwDhwNS22LKGBSmKwT3LlwqUm5/8Ou5zi84NYTe3E2m+f5dIgT
FeOHrKhunecas7f4mSg1Kx/W6XsCFYfRcuMyYGZM6Xp+85xsmudmc1OmMLfTvqJG
0jSM0ITMWAtALbSHlCHcZVrokbvqhiyrLuJknuQPeDmFaRXW8se34dRHalMVJsXe
qbT8na7Uk4juPhhhkfpr/7aEyOFGH+FSSGl0A/9ErPfiPZc4BQvu0RMbt3iSE3DZ
AWKTvYBeJ+578FQteQ==
=RB0d
-END PGP SIGNATURE-

php-8.0.0beta1.tar.xz
SHA256 hash:
d71592128156060501e4ba513a899a91bca25946e566f7ca34345ccd5945d072
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8poLsWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj3FEEAC4TatjmJDn3BlRk5GK7klNgxt6
4KU4W+raCxHOhGQJIiHn7QWnWTrdc/MFYQh9fIv/HkmzNHPp7ieK86BqL4+Jop8E
YNZ7/06gS/5jYI8EMyKlnX71uf7YmGgyC3AZndsI4YH+h/CvhsQf8BurC4geht0Z
9gx4rA5r6MwtliNTkCVXzQDqiKtd6DCcFxD9A8fyrpi9abyGTDXP711tiJpxe/aC
xrmelaEZgtdOAksES4VMCaeMZetv5++3I/UvUP6Afgw6C8m4YZMZO8poA3Yfk76D
HDDJlYqPPOZrhe0YVC64DDcqiTUSriAS7evn5KiBClKN6359Ey1tHc7NopPru8jQ
cD+cqa5sbIeNVjeNMgTQF3vwJQBwmnUdJYzfCaXKH6pViZbcjYvN5R5RnGxtI18O
yj5Jt+8zOHqzHuCUAj+RHT/4+AlPCsIHx+lqDArZIwsGtb7qozOE2iy8Aha0eD1w
vU36IWVBMI7GjjEhgIUYCDhUADURqPrUu1N4S/DGBgLqRhLpR29ZU/sDvNqSSZOz
5Hwg/bb5jnuaYSoOOKhojvHAaIUhw13d/qQQcDnoUxjIfuBRNb0SWIdIk6KCn6ho
msrX5xPawg+AYzKf7N6oRJus3Id05Dnsn4vi5Xs9i9vWluOGNLMSwN7tx8Mu/8X/
iAU8zGfl/gxeyx0tJA==
=CLuH
-END PGP SIGNATURE-
```

[PHP-DEV] PHP 7.3.21 Released

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.21.  This is a security release.

All PHP 7.3 users are encouraged to upgrade to this version.

For source downloads of PHP 7.3.21 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: 
Downloads:
Windows downloads:
Changelog:

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.21.tar.bz2
SHA256 hash:
dbb0ea39e7e4b3814d6d1dd3ac5983aed6c38cdf55464645da11a8b134a9f7a7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8pGIwMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2JkUP/3PYJ9MDXc/K0wJ0QO2Vv0WHRpKoi0qGCi/3diGY
Gw1JV62xa9L5etkIUizrDEqTlWyKRh2aDgMgKgqF9+CBgF7JEfad9jDkoxUDlb+1
k44pe2qwkep3vR+W/jQKROn/YdSeaI2/LfoI+FQ+85eCr8dlCDpR2LIvq47NnAIH
ac17up8iuw7EQ9Yr+xUU/IJ800cdzvyKJxfb83cVqVS5kV5dmsOYfVZlahgHh5J/
DUC87/wXaMndaAo/4auG0Nrfn27GVqnKNwgLTm4Qd/kh2SJm+IHPV5FAwGq1bgqb
1a0BnzjE8JuJSuMkITgYjkY6Rj5Qrs0OGQg1LciVxVwtFdpUrv2Azw6EicrbHb5A
9wrZndcGqz4pM+6gLkKCBYX6MXGMJR8dHCwi3ILejzpQ63rNVmzhIVvUjMTkSj6e
KUKbm9wXvv4SkTDVnZy7wFKARzlnsTp5sNuz+KKKzjCG8qRmjY0dVqnCa3adaEU3
gHK32Hm3yJUViFqkjiFiH8YSNeUpCwOyWmaYTejkRm+KfIIDZNavbWUr4+ncZvZ3
zTcZG4638E+SBPG6IQlzL76oQKj3v8Z2TmidYBKJva19pweBQNis01Q4q4wjoB2N
ofv/URSYijs9kn/GGAuscbrXGhxOrOW9V8bpyCQzSa2ng603Si3K6fEvm3EejgbQ
Fb6B
=1vns
-END PGP SIGNATURE-


php-7.3.21.tar.gz
SHA256 hash:
f5d6e136768522edd025c4a97b9b6a98a2fda20b68445cbc5ca2efce1e73c7d0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8pGJEMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2v6QP/3Q5fA6HOIGAI3Msi9n+ESHVjnt8/Hinp6KUFcj2
OKZ5pYsVCONcGeXccQ5DIiZ+TS6V+lFnSdNYWZVmJmkOdzTbzZt9G81QXauLTObB
IeXS69wb67OUdqWwwhtZKfcx+ubrQz5YlIS//+N2s/7oN3LJRLRv82yI8kD1YYkG
GYFZ95IFS/8UhROU9psrPUX7OC7fkan/V11pFtdenmWBiHOeIki5rtBK1jYd3APb
pL3wuQTqxGET/bK/91wAqL7UmHw/L/dzJC/azE29EArplvsMgmq/IZByey3CRExV
xpjfIpOZATqZp4GjUQo7KjVcPS9ePgs6bvjcyli59+TF9xyjrQxp0hCJqK4KASXZ
lUAhlsCo4Xvpp1JrhhZUuq7ts/FQj1fOLNb3cJ1sNOokwe25Hux4B0nc5AsAZHFs
eExLS1Ssvf49QrZEZIVMryPD2YJtRlHm+deMo0ICZq7DqtoLTBNnBgLfIoG+GErz
5lFYuaiRNZ3mMvlgLFQUZBp28TZTMV1S5JAtp2iMc+h0OFnXk/tSiGBfOzjMoFAF
dia6vP3C2AhV+kVm3d2mdicsSNOFlUDvmhM55VR2/IV1A/6UPsBO7rKo2ow2r8Rz
cdVD29t4cOAV5janwajusT0Yj6Bnjs+vNE6sgoaeZbOQ/F1iaWEDNYyPtdk1Hs2q
sB8l
=haxj
-END PGP SIGNATURE-


php-7.3.21.tar.xz
SHA256 hash:
4c8b065746ef776d84b7ae47908c21a79e3d4704b86b60d816716b8697c58ce9
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8pGJEMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2R44P/0KK8tU7FqDXrPhOlXEAtAB3Uaocw54A7gG/HwV1
QV4zUdlITUjuLAi8OHIWJmD/9ixc2EDnD35qkbQFP/8XnUoOZu2QkqKoUeIH5vP5
snmLY9tS9P6x/4GvV5zBtVNS0SgkTU/7ZUrL5QR7HxO7sBr2BZp+j2C2y7x23E7c
zGODXTTuY3U/57cYZdUsETxtI/MMI4N+gw9ypTPoLXtnmIaWeMvv330PlzRdAHw0
cNJ0BJYKmY8cxD5XQ+dIbUUKOo68+qjPdqlZyRQZ/zYxvJx60Rs3S7QzCb4IhuAz
aKPL/96Vq0cxuoEw3yBc/Umbh5xvbzjUmArmX0W6jGd11BhZisWXMgdq3KZa6kxY
zEVEL02ZhTI6A3NXao0w9/bXJUBJjyEVF+bIdy1sddLQTzVr8W6JC8vNM0U8Sir1
7TEv2ubQNnG1yE/v/eLRNThH5S4i6PZxdp/EhT5ZY36wYcgQ7hAjlgr3P4fwUzlu
6ggsApc/jdo8MHKEPyhsqX+Va5Pm9hlvsZwx+8sJ0Z5hGzkf9CCJnhaW8g9NsdPx
DTxZoZRZt/t62q0ECZDAFbplvcwLAFWc26099In/BasJxClKzWIu19Tf1nyuKLrZ
6cdXUqJeV6MYXtV8p2Lq6PegdwD9xVgk8gqhwsWTlI4mRwMedJEMMVWfh4DJEZzE
K5CU
=2e0a
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Re: @@Jit Attribute Considerations

[Aleksander Machniak]

On 06.08.2020 08:50, Dmitry Stogov wrote:
> My solution:
> 
> - remove doc-comment trigger. It doesn't make sense.
> - add @@Jit("off") only. Later we may extend this.

There are pros and cons to the "Jit" attribute name, please consider
@@JitOff (and @@JitOn).

Also make sure to define what happens if you use the attribute on a
function as well as class or e.g. class constant. In other words, when
it's not applicable will it be ignored or throw a warning/error?

-- 
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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

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

[Rowan Tommins]

On Thu, 6 Aug 2020 at 09:12, Benas IML  wrote:

>
> But by sacrificing a few very old codebases (that still use `#` not `//`)
>


Do you have some basis for # only being used by "very old" codebases? As
far as I'm aware, it's not deprecated, and while the PEAR style guide
listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.

I agree that it is probably rarer than //... and /*...*/ but let's avoid
unnecessary hyperbole.

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Benjamin Eberlei]

On Thu, Aug 6, 2020 at 9:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans  a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
>  there is the parenthesis around them. When there are no arguments I don’t
> see
>  the benefit of an ending delimiter, it’s easy to spot the end of the word.
>
> > - Doesn't allow grouping
>
> I do not understand this argument, what is the point of grouping for @@?
> Does grouping mean anything special for other syntaxes, or is it just to
> save
>  keystrokes? If it is just to get a more concise syntax when there are
> several
>  attributes, the fact that @@ do not need grouping is a pro, not a con.
>
> > - No forwards compat with PHP 7
>
> But no BC break either, while #[] introduces BC break.
>

This is **not** true. Both @@ and #[  will break existing PHP 7 code!

The question is how likely each of them is. #[ will be slightly higher than
@@ - but both will still be in the 0,01% range of occurrences.

and for *both* the same Fix is a project wide sed that replaces @@ with
@@ and #[ with #[ respectively.


> > - Not used ny another language
>
> @ is used by a lot of other languages, and @@ is the closest we can get in
> PHP.
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

[Rowan Tommins]

On Thu, 6 Aug 2020 at 07:40, Derick Rethans  wrote:

> On Wed, 5 Aug 2020, Rowan Tommins wrote:
> > The confusing thing about this argument is that as soon as they have
> > arguments, attributes will have an ending delimiter _whatever_ syntax
> > we choose, because nobody has ever proposed removing the parentheses
> > around the arguments.
>
> The syntax that would start it (@@) is not the same, or related to the
> parenthesis that follow the attribut name ( () ). They are not linked,
> as the ( in () is opening a 'context' and the ) in )) is closing it
> again. This is not the ending syntax of '@@'.
>



I'm sorry, I don't understand what you mean here. Are you saying that there
is some practical difference - for parsers, for human readers, or something
else - between the grammars below?

"@@", attribute-name, "(", expression-list, ")"

vs

"@(", attribute-name, "(", expression-list, "))"


Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] PHP 7.2.33 Released

[Remi Collet]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.33. This is a security.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.33 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: https://php.net/releases/7_2_33.php
Downloads:https://www.php.net/downloads
Windows downloads:https://windows.php.net/download
Changelog:https://www.php.net/ChangeLog-7.php#7.2.33


Many thanks to all the contributors and supporters!


Sara Golemon, Remi Collet




php-7.2.33.tar.gz
SHA256 hash:
97bb6b88ddfa44f36c4fc84a1a718faef476f61b532d26ea29e3e9f6cd79d839
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJfKRDcAAoJENyf+NPuWvJ/QYoP/3slqXlp8yx5juQEsMf56na1
Qnhf5NvKCJilANcDQb7COGYCPiO9Bg8WoqIdwXIgtYlPGUxTtohiuqr6BlN2PqAA
PhtUE7cmrXsJtIoOEwdEBuyxM8mjdOy1gld1fHr390OefcjvmT0H+mKeyJmPmvpk
xZREJjHF1nHmbD+7i9Ne2EayU9VFRxiTKLw7/QDJ4vezyZyVPzmpN6V0ROtjIoS+
TbCUQeqKqENGoeLB6sZfjwizX4oK7NPrel9LbjaRjnXObYixCmpXi/luNP+F9rgK
Visxdla61vqn6bTZrxws/EIilmXrdl2X8BN7iCkgAFP3pHjZ3WpSc6kul0gY1nyz
CwCU07vhmbeSOksoz4zBMhUvLUYsAMCBXqxgvlKTSLzwYzqPRjSXJn9Pc9cMPd+R
ZO1DSFIPVmr6VKYLWip2DN8sKDYfnEExxOaqHo2x3Zcwnam12iiYg+X5xD8MoXae
1+3QrzcF/RYKHCF6czsaluJUutBDtJbk8C9U8F1leD4cMCB6cMxQRVIagJyV/Hxl
7tFRjksz8dCNP+bC84lDQBOyaBVuHcfPIyGdVqqX8Z6PqDqimyNzsc1Agsv8dCKE
MulXNBfzMHi5ea+tYL3UUVrNcLlUKSAnxizupJt5BfkuzEzfRS7jIeM6XdRmTocM
I1JfnPnwMt5bpFzo56BA
=5pmK
-END PGP SIGNATURE-

php-7.2.33.tar.bz2
SHA256 hash:
03dda3a3a0c8befc9b381bc9cf4638d13862783fc7b8aef43fdd4431ab85854d
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJfKRDeAAoJENyf+NPuWvJ/u3wP/3Kzzqt8EUwhRlA3fCV1jZrX
BnhsteT7Bpe9R7WxNeLWE8FhuqVWRHDIPExjyBf5on/s/XYLCiBHFY0kPdb+wY1o
IQ+VSRmggs4ca2wTOJEZXYYiTX8NnWMkoW+NihkD5bxlzus9oxDl+tovucyP1dwc
aAqtW9CbA+3lo/UE5iqQA1EPWxsmDNrKIqHsApd5BgPPFW/l0Bfr+LqeY4s2LO4J
o9Kpx9NztaF40mlAd+89Hao0iwkI2CYkk8M1UxT14VPPRm0z59aHj6aS9Yp5DCWt
vu+3X6ttykRuD1/L9/aX8Hngx8Mptjyxkvp5vskaSg624QUsG8zR/3cTTCfK1fnI
fOQwePd6GYBxwqzdOLp8UYaOA19Xy+lOpJL5aqTXD9PQH/jqy8WSZh5JRvpsHYTc
ZlLTTJG1Vp44+RZtrrZM/9KcTfUk5E3FNdT+oXVZBHXrQINil9ziZUXNh83BlVLA
ytzf8LfHup+BIWqWuTnzXCTN4JbhiwlnP3ospvHDXIr6UIt5P66gzmUnMM3O0Isp
Uui/eTiModfFeaEMK730zl46npu90cieyar2CZDIpEDyjDyyTYyQdi3RUHSfZeTZ
cfVDuBsvVqM31FV7kxHSDA1dcDjFSQcb/S8YeTsZkEbCZWC5gHTRkUmIktq7MBjy
Ojej5xzwDPJmwhB5X1o2
=Iamw
-END PGP SIGNATURE-

php-7.2.33.tar.xz
SHA256 hash:
0f160a3483ffce36be5962fab7bcf09d605ee66c5707df83e4195cb796bbb03a
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJfKRDhAAoJENyf+NPuWvJ/3DQP/3vgghiSAL3odrN4gTw3ZwS5
RAFpNMTtOD7/jWzbTCVca0TmocjNLoS9Mp1GpGJjyaz+APSPuWMqvi17S5TgU2hG
eGcaCyuRA+U/37uNUR7fO8gpow9M0FvMJ7XZABXVql1L3gQkrZ6fTpI22BQ8cZGC
k4QoYMLomrU0aSLMuUUUkNqTKe3/mQjkgbHg9lPEeQkCDDHtLjzqPXl9vzDrDj+S
RWploMyixvh/e1HSinMzApYIjnUQ4y1iMN8IFkZUhj9TzX6cNdNiMhjpemsQmX9I
YZwwnxZ9uoBx5guU5zqhhW/Ajm8OkbRNobXuizdPHMrKEOPyydYZYYEoVJqGmhtB
02MKYMVfxz5cNBA543fiMoDNb+1AxNMD2CKYmlKbeqqt1zNvauZ/49H8AJhVJGUA
3ihPuJqEUFIleP/bujaHilLLIM8+N8VzOvUEAsColsxoYckZeamZNYppVb3YGoCD
nQUuwAUEXAUbZiZsSQMZJMybjpjS9whqUKeLIjP7MrDDBB2jP+D34s2SVJmTJdyU
dKmAxiP4WLHfkUulA+gk7cmEzqKBrmSgHhQCdHvSJr0Ng6oWSSouGbgFd6dnv8+h
qPBx48s7g0+w6ozEs04xQ5Y8RRdxBj71nPL20aJHWQmyfMbJmDwfwuTrEpN4zHD6
ONdwHXj1oT6gXu5OFuEZ
=Ku/n
-END PGP SIGNATURE-

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

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

[Benas IML]

On Thu, Aug 6, 2020, 10:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans  a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
>  there is the parenthesis around them. When there are no arguments I don’t
> see
>  the benefit of an ending delimiter, it’s easy to spot the end of the word.


Ending delimiter MAY help us in the future.

I really, really hate all of those arguments stating "that we should care
only about the present, not the future" and that even though
`#[...]`/`@[...]` might bring benefits in the future, we should still
choose `@@`".

This shows clearly that some people are basing their views on subjective
reasons rather than being objective.

As far as this discussion is going, I see pro-`@@` people just saying
"Arghhh, let's keep @@, it doesn't bring any benefits that other syntaxes
do but we don't need them anyways, let's not speculate future".

It's like saying you can either go through door A and get a free car or
through door B and get the same car and **maybe**, even an additional
1,000$.

We are playing probabilities here but at the moment, no one has said any
substantial argument why `@@` is better and thus, `@[...]` seems like a
better option in the long term.


> > - Doesn't allow grouping
>
> I do not understand this argument, what is the point of grouping for @@?
> Does grouping mean anything special for other syntaxes, or is it just to
> save
>  keystrokes? If it is just to get a more concise syntax when there are
> several
>  attributes, the fact that @@ do not need grouping is a pro, not a con.
>

No, it is not a pro. It's a matter of personal taste. You are basing your
opinion on subjective views which goes against this RFC's principles - to
choose a syntax that is the best based on the benefits it offers.

> - No forwards compat with PHP 7
>
> But no BC break either, while #[] introduces BC break.
>

Not true, technically speaking both `@@` and `#[]` have a BC break. Albeit
`@@` has a smaller one.

But by sacrificing a few very old codebases (that still use `#` not `//`),
we are making sure that we won't run into any parsing problems in the
future. And this is far more important.

> - Not used ny another language
>
> @ is used by a lot of other languages, and @@ is the closest we can get in
> PHP.
>

This is a pointless argument.

`[...]`/`[[...]]` is also used by a lot of languages, `#[...]` and `@[...]`
is the closest we can get to that.

Heck, `@[...]` is the closest to both `@` and `[...]`.

Best regards,
Benas

>

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

[Peter Bowyer]

On Thu, 6 Aug 2020 at 08:18, Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> As said before, it does have an ending delimiter when they are arguments
> since
>  there is the parenthesis around them. When there are no arguments I don’t
> see
>  the benefit of an ending delimiter, it’s easy to spot the end of the word.
>

And if needed, make the parenthesis required. So @@Foo is illegal,
but @@Foo() is allowed.

Required parenthesis is familiar to most PHP programmers (functions,
classes following common coding conventions) - what's not to like?

Using "^" in the code demonstrations below as no one has proposed it and my
point isn't about #, << or @@ we get:

^Foo(
  ^Bar(43, "raa")
)

vs

^[Foo(
  ^[Bar(43, "raa")]
)]

To me the former is significantly more pleasant to read.

Is it difficult to parse?

Peter

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

[Côme Chilliet]

Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
Derick Rethans  a écrit :
> From the RFC:
> - No ending delimiter

As said before, it does have an ending delimiter when they are arguments since
 there is the parenthesis around them. When there are no arguments I don’t see
 the benefit of an ending delimiter, it’s easy to spot the end of the word.

> - Doesn't allow grouping

I do not understand this argument, what is the point of grouping for @@?
Does grouping mean anything special for other syntaxes, or is it just to save
 keystrokes? If it is just to get a more concise syntax when there are several
 attributes, the fact that @@ do not need grouping is a pro, not a con.

> - No forwards compat with PHP 7

But no BC break either, while #[] introduces BC break.

> - Not used ny another language

@ is used by a lot of other languages, and @@ is the closest we can get in PHP.

Côme

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

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

[Derick Rethans]

On Wed, 5 Aug 2020, Rowan Tommins wrote:

> On 05/08/2020 18:10, David Rodrigues wrote:
>
> > With error supression remotion (9.0?) it could be used for other new 
> > features easily.
> 
> 
> Just to re-iterate something that I'm pretty sure has been said 
> before: the chance of removing the error suppression operator in PHP 
> 9.0 is approximately zero, and the chance of immediately re-using it 
> is significantly lower.

Hear hear.

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] Re: @@Jit Attribute Considerations

[Dmitry Stogov]

My solution:

- remove doc-comment trigger. It doesn't make sense.
- add @@Jit("off") only. Later we may extend this.


On Tue, Aug 4, 2020 at 11:11 AM Benjamin Eberlei 
wrote:

> On Mon, Aug 3, 2020 at 7:44 PM Benjamin Eberlei 
> wrote:
>
> > Hi,
> >
> > I am going to pick up a discussion from
> > https://github.com/php/php-src/pull/5915 about the @@Jit attribute.
> >
> > Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
> > attribute and asked to discuss here.
> >
> > The reason is that the default tracing JIT is clever to decide itself
> when
> > to JIT or not, better not interfere with that. In case you run the
> tracing
> > JIT, only @@Jit("off") has an effect the others @@Jit("tracing") and
> > @@Jit("function") get ignored.
> >
> > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> > and "function". This trigger mode feels like micro-management for
> > developers and since it has virtually no spotlight in discussions and
> blog
> > posts about the JIT at the moment, we don't know if it brings benefits.
> >
> > Maybe for now it would be better to remove docblock / attribute support
> > for the JIT, and take a new attempt at it in 8.1? That prevents us from
> > rolling something we regret having to maintain later.
> >
>
> I updated the PR https://github.com/php/php-src/pull/5915 with the
> following things:
>
> - Removed attribute trigger mode for now.
> - Removed obsolete doc comment trigger mode
> - Add @@Jit("off") to disable JIT for an op_array or script
>
> Open questions:
> - Are we ok with removing @Jit("on"), @@Jit("tracing") and
> @@Jit("function") for now to thoroughly discuss best approach for 8.1?
> - Rename @@Jit to something more specific like @@JitOptions or @@JitHint?
> - Remove the attribute trigger constant 4, and move tracing JIT to use 4
> instead of 5?
>
> Outlook:
>
> We need to think about what the @@Jit attribute should actually mean in
> context of the function or tracing JIT. Personally it probably means
> "Always Jit this function regardless of hot counter or tracing results".
> I believe we don't need the attributes trigger mode, as everything happens
> either in context of function or tracing JIT.
>
>
> > greetings
> > Benjamin
> >
>

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

[Derick Rethans]

On Tue, 4 Aug 2020, Theodore Brown wrote:

> 
> #[Attr1, Attr2] # 15 chars
> 
> @@Attr1 @@Attr2 # 15 chars
> 
> # 4 lines, 53 chars not counting whitespace
> @[
> AttrWithParam("foobar"),
> SomeOtherAttr("fizzbuzz"),
> ]
> 
> # 2 lines, 52 chars
> @@AttrWithParam("foobar")
> @@SomeOtherAttr("fizzbuzz")

Shall I do one where we count pixels? Because @@ is using a lot more of 
them... And there is also no reason why it can't be just:

@[AttrWithParam("foobar")]
@[SomeOtherAttr("fizzbuzz")]

Although group is allowed, it doesn't mean it's always useful to do.

@@Attr1 @@Attr2 

Seems to me like a cat had trespassed on your keyboard, the *heavy* @@ 
also dominates the line.

> I agree that we want the best syntax, not necessarily the best 
> **looking** syntax. I still believe that the @@ syntax offers the best 
> balance here.

>From the RFC:
- No ending delimiter
- Doesn't allow grouping
- No forwards compat with PHP 7
- Not used ny another language

And the "familiar with docblocks" is quite a stretch, as that doesn't 
use @@ either. I've only included it because it would be unfair if @@ 
had nothing positive going for it.

cheers,
Derick

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

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

[Derick Rethans]

On Wed, 5 Aug 2020, Rowan Tommins wrote:

> On Wed, 5 Aug 2020 at 13:20, Benjamin Eberlei  wrote:
> 
> > It looks nice for a simple attribute like @@Jit, or for a one 
> > without arguments like the used @@Deprecated, but as soon as there 
> > are more than one, and they each get arguments, enclosing them has 
> > its own benefits over them just standing for themselves.
> 
> The confusing thing about this argument is that as soon as they have 
> arguments, attributes will have an ending delimiter _whatever_ syntax 
> we choose, because nobody has ever proposed removing the parentheses 
> around the arguments.

The syntax that would start it (@@) is not the same, or related to the 
parenthesis that follow the attribut name ( () ). They are not linked, 
as the ( in () is opening a 'context' and the ) in )) is closing it 
again. This is not the ending syntax of '@@'.

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