Re: [PHP-DEV] Null-safe property access in interpolated strings

[Björn Larsson]

Hi Ilija,

Den 2020-08-10 kl. 17:06, skrev Ilija Tovilo:


Hi Nikita


I think if it can be reasonably fixed it probably would make sense for
consistency and WTF-avoidance if anything.

Agree. I don't think the question of whether it is useful should come into
this, it's a matter of language consistency. There could be some leeway
here if we say that we have plans to deprecate the "$x->y" syntax in the
future anyway and don't want to extend it anymore -- but I don't believe we
have such plans at the present time.

So for the sake of consistency let's merge this then. As mentioned,
the BC break should be very very small. A few people have mentioned
they didn't expect it to work but when asked again they didn't feel
strongly about it.

Unless there are objections I will merge this tomorrow. A review of
the PR would also be welcome.

Ilija


I second Nikitas opinion that consistency is important here. One shouldn't
need to spend time as an PHP end user wondering why we have a special
case that doesn't work like the rest!

Good luck with merging.

r//Björn L

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

Re: [PHP-DEV] Null-safe property access in interpolated strings

[Mike Schinkel]

 
 

 
 
 
>  
> On Aug 10, 2020 at 11:02 AM,  mailto:tovilo.il...@gmail.com)>  
> wrote:
>  
>  
>  
>  Hi Mike  >  $card_html =  <<  {$card->content}HTML; Two things: 1. We're solely 
> talking about string interpolation without braces {}. You're using braces in 
> your example and this does indeed work right now. 
>  
>  
>
>  
>
>  
>

 
Thank you for clarifying.That was not obvious to me.  
 
 
 
 If it was explicitly mentioned in the thread and I missed it, I apologize.
 
 
>  
>  
>  2. The semantics of ?->  are different than you're depicting them to be in 
> this example. ?->  will only short-circuit if $card is null, not when the 
> property "css" is not defined. Thus, if $card was null your example would've 
> already failed at $card->id. 
>  
>  
>
>  
>
>  
>  
 
 
 
 
Good point. I was remembering a frequent problem but did not convey the 
use-case correctly so please let me update it:
 

 
>  
>  class="card {$card->attributes?->css}" 
>  
>  
>  
>
> The only real information I was trying to convey was that when 
> generating HTML there is a frequent need to output a value if one exists but 
> output nothing otherwise. So hopefully this time I got the usage correct for 
> this new feature.
 
 
 -Mike
 
 P.S.I would have tested it before sending, but I do not have a local PHP 
install that I can test this syntax with yet.
 

 
 
>  
> >  
> >  
>
>  
>  
>  
>  
>  
>  
>  
>
>  
>  
 
>  
>  
>
>  
>
>  
>
>  
>
>  
>
 
 
   

[PHP-DEV] PHP 7.4.9 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.9. This is a security bug fix release.

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

For source downloads of PHP 7.4.9 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.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.


php-7.4.9.tar.gz
SHA256 hash: c0c657b5769bc463f5f028b1f4fef8814d98ecf3459a402a9e30d41d68b2323e
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8pIrQACgkQkQ3rRvU+
oxJfKA//dHdIcIVUybwJcwBSNBT8t/hzbXsFqs7QynKBx+ADeZVXv3tuaC5pwLrE
AwwJMmx5oz1DgbyNwK/wCldNrc9/+12wPwoqrWjr+RtzFCcIu5raRdtYBwpvX++/
nj+VYLNy4w7WhGAPzKVHUmx0mtBV1ZV5UZlXAwlI1yD76LnijxVbR2klEf3Zp3GX
KbABPDfckZu5COHkpDXRaDdCbk3gqzMwtem8M5yJQPPjlSFLAGfnxEpmgKEfCHdW
id9AjiGOlg7ZmSwKIg69NQWV3mGoSKXI6LUt1FQTBoyaZqPBqnlfnSazdxsNsnzl
JfU056snIne3dQei0prR4nEUJqJbNXPtJ0bF/KojJrTdR1mG3EFX5rJVmabNxHlH
lLLZz3Cd+h03HHHt9juR980LgA2di5fcBq/2qqcYCovWXQBpr/TkfjdVByha11r1
RZL5gQdjnlSFn5HxqZTMCfUdELlFzRSAxDjWb9ChZDMe8MOVXdDnQFIZdh4c2Od4
OgwAPaGL/fXY2txIyu6jEGG8EdtnTcsO65Nr+MdRkfgbW8NPWp7FqrNN+kUXn2C0
kFU6UeyK0zF9tSu9p9ctuxZYzKZALn83N8Ane/dO2eQUVSfhE6H+q7dwPyLhr7Jz
vcIaImSrKR7vZFxSbaZo1aUA4rszkmGahi2N4MaVV2d8MxXDMPE=
=y467
-END PGP SIGNATURE-

php-7.4.9.tar.bz2
SHA256 hash: 2e270958a4216480da7886743438ccc92b6acf32ea96fefda88d07e0a5095deb
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8pIrkACgkQkQ3rRvU+
oxLZaQ//Wk8PO6/IhKmqQkyUFayDHJnFE95ZxA3GBkOmVEgtaGTc5TeaLup8lGFb
TQL1u3wzIy7tX1puSI4krhtVdh95GFYpD1dARwzOZLEpwrZSnWXgnkv6HuyeEosh
S4rk1mZX3flkgJewZGc8/yvomZYx4yYq5iTAnlYmzSLqxKYVzCCHyLAeL9ucZplH
eF3W2wa/pBvheNKl/+7pnZ1obH1JMMZ4aW4vcV2rwP2V3uf37XTVmJv+1aHFxI7E
G0OaorQgmto5ckghV8H2AJZpFdV+tx5/zytI49BzkJ5Dw7APiKRGE110JdVvPh/z
Cehf1zq6IRgtQdrPw1WQxQFAANAs8Z48cUYFQV9AjOYTrWqWzoxf0CrpDhDZhMaL
07/wMDW0Ajv2S0cMfNYUODCiLtYUrW0hKweIVsQvHhVkbLyuk2gEfv74Y2MByV5X
Q42GBzgkc5RnLGYGJugTZZ1/bfn++u4aS1hawGNwovonJwIKnQ/5q7q/GZSkXzOg
VYLrUOiLGh6r7M+nHRpIxuqeYO6vImMiihG7UvnV/qJRxO/eRgfwWAEkBJZ8/QYy
4h5usQMZjB+7K3wjjU7TeKZdvXGsLttxXxoXDTgZMH4tl7euGG+kJqUusVHa+hgS
Wk8bu9PvnZivtIhF7A9hViiRCV0kGkF3WdBmFJp2cVBtscczLHU=
=BrDy
-END PGP SIGNATURE-

php-7.4.9.tar.xz
SHA256 hash: 23733f4a608ad1bebdcecf0138ebc5fd57cf20d6e0915f98a9444c3f747dc57b
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8pIroACgkQkQ3rRvU+
oxKXshAA38vW2zBHGAjbqFWAQelX7Qu7psPOzwoxsVOcWakJm+Jf4+e9LYoWEMYO
NInMJGxzIsovjy+NBnoF83vaNY7TN+EbSYsqfbNX1+/WvPNHWFOoWNdOvMMTpuZy
0N0TJx/6dEfyQLwtxUdPGWFoGK/Nh7BvWSmVj5R3nSKOtx0W5rYWVSt7+loTCOcv
36NYJvuTej4SBrMgAlswYtw/tTtyRhMXYsgBzVKsgEXdIwGeWRiymjal5QdR/Ja0
78Neh5QZlDaR+rqYPMmXRAHp7Y0sMVqgQjuPOMf63mK5zazRuoni2uU8Yb2bghWb
WmltKZW7xE8d/F0h2IZ6T1Kk1kS9D9S8KBvkfBbCMYp5bJEbAoSZ5aIW1BSs0FR6
nX7GYeHPX6nuT53DWfmr/021qG5jFRcE9oRpRFNVvUGrKGWdC0H7zygXIErPxrJm
E5fuawdL6N+ptHpbY6gkLbbaJi6dnCf9JteLXWQKbynLH7zBoBaZZPoxwejIJfYD
AvYmfzVSp39P8DJZX7/OBvWbl7QRRyWtXSU/jzlYug+EdjUDEOgNfRGgeEnbr1S1
VrYoZGuRYEwf+c4oWrGdKkqigIj1iDWEIy5/EmKPo4btWdrHGfNZusRUG5Z6pNWw
mO5vRmvlJObD2D2Q1HLhZCwARBtDRmMqdmFN+pnTj4kSg3IMhpg=
=8CbX
-END PGP SIGNATURE-


-- 
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] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 10.08.20 17:40, Derick Rethans wrote:

It missing an ending delimiter was my first reason for wanting to get
something better than @@. I don't particularly care much if it ends up
being @[], #[], <<>>, or other things such as @:( ).

If you have something to open, and close, there there is a distinct area
that forms the whole definition of a thing. That's why functions, and
classes have { and }, if and other control structures have ( .. ), etc.

Being able to define a whole "thing" easily with an open and closing set
of symbols, allows for better mental parsing. It also means that syntax
highlighting tools can map the opening part with the closing part. (VIM
for example, uses the % character to jump between opening and closing
symbol).


For me the difference would be that with attributes, you are not opening
and closing many possible statements, it can only be one (or more, with
grouping) class name(s), which then can have arguments, but those are
enclosed with (). In comparison, classes can have many possible
definitions inside of them (class variables, methods, constants, etc.),
so enclosing them clearly makes sense, as you need to know where it
ends. The same goes for if, for, while, etc.

So if you just have one class name as an attribute, enclosing it seems a
bit overkill, as there is already a definition of a class name and how
it starts and ends, which is why for me the mental parsing does not seem
easier - but what is easily parseable probably depends on many factors
and might be different for different people.

I would have found a syntax where the delimiters are optional preferable
- similar to "if", where you can leave off the {} for exactly one
instruction, but you have to add them if there is more than one line of
instructions. Or the group use syntax.

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

Re: [PHP-DEV] ZEND_ENGINE_4 define?

[Sara Golemon]

On Mon, Aug 10, 2020 at 2:37 AM Nikita Popov  wrote:

> On Mon, Aug 10, 2020 at 7:57 AM Philip Hofstetter <
> phofstet...@sensational.ch> wrote:
> > In many cases, I've been using the ZEND_ENGINE_3 define to handle the
> > PHP 5/7 difference.
> >
> > Now, the Zend Engine version seems to have been increased to 4
>
> I would recommend using PHP_VERSION_ID.
>
> I have no idea why we have the ZEND_ENGINE_3 constant, but it seems like a
> pretty bad idea. Now that we are at ZE 4, should we drop that constant --
> and break all the code using it? Chances are that code guarded by
> ZEND_ENGINE_3 is also needed on all versions of ZE going forward, not just
> ZE 3 in particular. I think we should just leave teh ZEND_ENGINE_3 define
> around, but make sure not to introduce a new one of that kind.
>
>
I agree that ZEND_ENGINE_n was always a weird constant, and IIRC we had the
7.x series export both ZEND_ENGINE_2 and ZEND_ENGINE_3.  Not sure. (and the
fact I'm not sure is also telling).

This is probably much more expressive:  #if PHP_VERSION_ID >= 8
If one *really* wants "Zend" versioning, you similarly could do: #if
ZEND_EXTENSION_API_NO >= 4

How many version indicators do we need?

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

On Mon, 10 Aug 2020, Andreas Leathley wrote:

> On 10.08.20 15:05, Markus Fischer wrote:
> > Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>`
> > in fact is the most "unreadable" version to me because duplicate
> > occurrence of a single character somehow creates a noise _for me_,
> > 
> > I don't feel eligible to have a vote, but based on that and certainly
> > aware IDEs in the future will help with this, I would vote for
> > _anything_ not duplicating characters, i.e. favoring `#[]` or `@[]`
> 
> It is a pity that syntax with ending delimiters and syntax with no
> ending delimiters are now mixed in the discussion, instead of first
> finding a concensus if delimiters are even needed or what
> advantages/disadvantages they have.

It missing an ending delimiter was my first reason for wanting to get 
something better than @@. I don't particularly care much if it ends up 
being @[], #[], <<>>, or other things such as @:( ).

In my original email, I solicited other syntaxes (with patches), but 
none were brought up.

> Because there are many alternatives in terms of syntax - looking back 
> at the very first vote about attributes the @: syntax doesn't seem so 
> bad, if no ending delimiters are needed. In the new RFC all 
> alternatives to @@ have delimiters and it is suggested having them is 
> good, yet the possible advantages of delimiters are never explained, 
> ideally with some real-world examples showing why delimiters would be 
> good to have.

If you have something to open, and close, there there is a distinct area 
that forms the whole definition of a thing. That's why functions, and 
classes have { and }, if and other control structures have ( .. ), etc.

Being able to define a whole "thing" easily with an open and closing set 
of symbols, allows for better mental parsing. It also means that syntax 
highlighting tools can map the opening part with the closing part. (VIM 
for example, uses the % character to jump between opening and closing 
symbol).

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] Null-safe property access in interpolated strings

[Ilija Tovilo]

Hi Nikita

> > I think if it can be reasonably fixed it probably would make sense for
> > consistency and WTF-avoidance if anything.
>
> Agree. I don't think the question of whether it is useful should come into
> this, it's a matter of language consistency. There could be some leeway
> here if we say that we have plans to deprecate the "$x->y" syntax in the
> future anyway and don't want to extend it anymore -- but I don't believe we
> have such plans at the present time.

So for the sake of consistency let's merge this then. As mentioned,
the BC break should be very very small. A few people have mentioned
they didn't expect it to work but when asked again they didn't feel
strongly about it.

Unless there are objections I will merge this tomorrow. A review of
the PR would also be welcome.

Ilija

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

Re: [PHP-DEV] Null-safe property access in interpolated strings

[Ilija Tovilo]

Hi Mike

> $card_html =  << 
>  {$card->content}HTML;

Two things:

1. We're solely talking about string interpolation without braces {}.
You're using braces in your example and this does indeed work right
now.
2. The semantics of ?-> are different than you're depicting them to be
in this example. ?-> will only short-circuit if $card is null, not
when the property "css" is not defined. Thus, if $card was null your
example would've already failed at $card->id.

Ilija

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

On Mon, 10 Aug 2020 at 14:59, Derick Rethans  wrote:

> I did answer that as a reply to Rowan:
>
> https://externals.io/message/111312#111346


I'm with Rowan's response to you: https://externals.io/message/111312#111354

What is the difference between mandatory parentheses giving:

<><>(
<><>(<>),
42
)

and:

<>[<>(
<>[<>(<>)],
42
)]

in terms of parsing, use etc.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Mon, 10 Aug 2020 at 14:56, Benjamin Eberlei  wrote:

>
> On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins 
> wrote:
>
>>   The question asked was that _if the parentheses were made mandatory_,
>> would
>> this provide the same benefits ascribed to the other syntaxes?
>>
>
> For me It would indeed make a slight difference...
>


Sorry, I'm as confused by this answer as I was by Derick's. Is that a "yes,
it would solve the same problems", or "it would solve some problems but not
others"?

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benas IML]

On Mon, Aug 10, 2020, 4:28 PM Theodore Brown  wrote:

> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> >
> > The first vote is a vote to say that you have an opinion about attribute
> > syntax. Make sure to read up on the discussion on the mailinglist if you
> > haven't done so yet.
>
> I voted "No", as the primary premise for this RFC is fundamentally flawed:
>
> > The main concern is that @@ has no ending symbol and it's inconsistent
> > with the language that it would be the only declaration or statement
> > in the whole language that has no ending termination symbol.
>
> As I pointed out in the discussion thread, this simply is not the case.
> Attributes are not standalone declarations or statements, but modifiers
> that always come before a declaration and add metadata to it. This
> is consistent with visibility modifiers and type declarations (which
> are not necessarily a single word):
>
> # declaration modifiers do not have end/grouping symbols like this
> @[MyAttr([1, 2])]
> [public] function foo(@[Deprecated] [int|float] $bar) {}
>
> # this is more consistent:
>
> @@MyAttr([1, 2])
> public function foo(@@Deprecated int|float $bar) {}
>
> > The second vote is an STV vote.
> >
> > In STV you SHOULD rank *all* choices, but don't pick the same one more
> > than once, as that will invalidate your vote.
> >
> > Please have a objective look at the table
> > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> > don't just go by asthetics.
>
> I find this table to be unfortunately incomplete. E.g. why doesn't it
> bold the number of required characters for @@, since this is one of
> its advantages? And


IMO there's literally no advantage in typing one less character. Because if
there is, let's also shorten all of our function names i. e. `strlen` to
`sl` and `gettype` to `gt`.

why is "Allows Grouping" marked as an advantage
> for the other three syntaxes? Grouping adds implementation complexity,
> leads to unnecessary diff noise, and is rarely more concise than @@ in
> real-world use cases.
>

I'd like to remind other internals that there is no "added complexity"
(unless someone is unable to understand 20 lines of code) and it's
misleading to say otherwise.


> I also find it concerning that the RFC doesn't have an example for each
> consideration showing how one syntax addresses it better than another.
> For example, the Shorter Attribute Syntax RFC showed potential nested
> attributes and how @@ would support them more cleanly, but this RFC
> fails to mention them anywhere.


Syntax choice DOES NOT affect how "cleanly" we can support nested
attributes. AFAIK simple recursion would allow to implement those with any
attribute syntax with exactly the same code.


> Finally, while the table mentions that each syntax other than <<>> has
> a BC break, I think it's just as important to consider the *size* of
> the breaking change. #[] and @[] are larger BC breaks than @@ since
> they break useful syntax:
>
> // with #[]
> #[x] code like this would break
> $val = ['new value']; #['old value'];
>
> // with @[]
> $x = @[foo(), bar()]; // this code would break
>
> Both of these are useful patterns, and I'm not convinced that breaking
> them is justified. Shouldn't there be a Backward Incompatible Changes
> section in the RFC with these examples?
>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

On Mon, 10 Aug 2020, Peter Bowyer wrote:

> On Mon, 10 Aug 2020 at 10:15, Rowan Tommins  wrote:
> 
> > I am not a fan of the @@ syntax, and respect what you're trying to do with
> > this RFC, but am disappointed you haven't engaged with those of us who said
> > that the RFC needs more detail. There is simply not enough information in
> > that table to "have an objective look", and the only other text in the RFC
> > makes a vague assertion about the lack of ending symbol which I still don't
> > understand the significance of.
> >
> 
> I have voted no because I asked a question about the ending delimiter and
> why () didn't count. Another person asked a similar question and neither of
> us got a reply.

I did answer that as a reply to Rowan:

https://externals.io/message/111312#111346

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] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 3:52 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi,
>
> One question I'd like answered is that, like me, a few people have
> voted NO on the question to re-vote the syntax.
> If that is true, shouldn't their first primary choice be implied to be
> <<>> instead of anything else? I see 7 votes for no, but I'm the only
> one that still kept the first voting choice as <<>>.
>

At this point voting NO on the primary vote means that you are either:

1. are not ok with revolting this late in the release cycle
2. want to keep @@, because this is the current syntax (not <<>>)


> On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins 
> wrote:
> >
> > On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei 
> wrote:
> >
> > >
> > > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer <
> phpmailingli...@gmail.com>
> > > wrote:
> > >
> > >>
> > >> I have voted no because I asked a question about the ending delimiter
> and
> > >> why () didn't count. Another person asked a similar question and
> neither
> > >> of
> > >> us got a reply.
> > >>
> > >
> > > () does not count as ending symbol, because it is not required, as such
> > > its not an ending symbol.
> > >
> >
> >
> > The question asked was that _if the parentheses were made mandatory_,
> would
> > this provide the same benefits ascribed to the other syntaxes?
> >
> > To avoid repeating myself, here are the previous posts where I elaborated
> > on this question:
> >
> > * https://externals.io/message/111312#111342
> > * https://externals.io/message/111312#111354
> >
> >
> > Regards,
> > --
> > Rowan Tommins
> > [IMSoP]
>
>
>
> --
> Guilherme Blanco
> SVP Technology at Statflo Inc.
> Mobile: +1 647 232 5599
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Null-safe property access in interpolated strings

[Mike Schinkel]

 
 

 
 
 
>  
> On Aug 9, 2020 at 3:00 PM,  mailto:deleu...@gmail.com)>  wrote:
>  
>  
>  
>  I like and make use of interpolation, but I can't think of a use case for 
> this. Is there any valid use case that would benefit from this fix regardless 
> of personal preference? In other words, where would one use string 
> interpolation with an empty string being a valid case? 
>
>  
   
   
 While I agree with Jordi and Nikita that language consistency is the important 
metric, here is a valid case I   come across frequently; the need to output 
optional CSS classes since you ask, fwiw:  

 
>  
>  
>
>  
>
>  
> id}" class="card {$card?->css}">  
{$card->content}HTML;
 

 
-Mike
 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins 
wrote:

> On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei 
> wrote:
>
> >
> > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer  >
> > wrote:
> >
> >>
> >> I have voted no because I asked a question about the ending delimiter
> and
> >> why () didn't count. Another person asked a similar question and neither
> >> of
> >> us got a reply.
> >>
> >
> > () does not count as ending symbol, because it is not required, as such
> > its not an ending symbol.
> >
>
>
> The question asked was that _if the parentheses were made mandatory_, would
> this provide the same benefits ascribed to the other syntaxes?
>
> To avoid repeating myself, here are the previous posts where I elaborated
> on this question:
>
> * https://externals.io/message/111312#111342
> * https://externals.io/message/111312#111354


For me It would indeed make a slight difference, but not wanting to speak
for Theodore, I believe he did not want to add this as another option to
vote upon, when I asked him. based on the argument that new also doesn't
require () it makes sense to me.

And for me I didn't want to add it, because then we can just go back to
<<>>, which would at least be symmetrical. I.e. @@Jit() vs <>

>
>
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 10.08.20 15:05, Markus Fischer wrote:

Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>`
in fact is the most "unreadable" version to me because duplicate
occurrence of a single character somehow creates a noise _for me_,

I don't feel eligible to have a vote, but based on that and certainly
aware IDEs in the future will help with this, I would vote for
_anything_ not duplicating characters, i.e. favoring `#[]` or `@[]`


It is a pity that syntax with ending delimiters and syntax with no
ending delimiters are now mixed in the discussion, instead of first
finding a concensus if delimiters are even needed or what
advantages/disadvantages they have. Because there are many alternatives
in terms of syntax - looking back at the very first vote about
attributes the @: syntax doesn't seem so bad, if no ending delimiters
are needed. In the new RFC all alternatives to @@ have delimiters and it
is suggested having them is good, yet the possible advantages of
delimiters are never explained, ideally with some real-world examples
showing why delimiters would be good to have.

--
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 Mon, 10 Aug 2020, Christoph M. Becker wrote:

> On 10.08.2020 at 10:35, Derick Rethans wrote:
> 
> > On Fri, 7 Aug 2020, Theodore Brown wrote:
> >
> >> - Used by other language:
> >> - This is listed as an advantage for `#[]` and `<<>>`. However, the 
> >> table
> >> fails to point out that Hack is migrating away from `<<>>` to `@Attr`.
> >
> > It can only do that because they are removing @ as the shut up operator,
> > which ain't going to happen in PHP.
> 
> If we could afford the luxury of removing the @ operator, would you
> prefer @ for attributes?

No.

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] [VOTE] Shorter Attribute Syntax Change

[guilhermebla...@gmail.com]

Hi,

One question I'd like answered is that, like me, a few people have
voted NO on the question to re-vote the syntax.
If that is true, shouldn't their first primary choice be implied to be
<<>> instead of anything else? I see 7 votes for no, but I'm the only
one that still kept the first voting choice as <<>>.

On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins  wrote:
>
> On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei  wrote:
>
> >
> > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer 
> > wrote:
> >
> >>
> >> I have voted no because I asked a question about the ending delimiter and
> >> why () didn't count. Another person asked a similar question and neither
> >> of
> >> us got a reply.
> >>
> >
> > () does not count as ending symbol, because it is not required, as such
> > its not an ending symbol.
> >
>
>
> The question asked was that _if the parentheses were made mandatory_, would
> this provide the same benefits ascribed to the other syntaxes?
>
> To avoid repeating myself, here are the previous posts where I elaborated
> on this question:
>
> * https://externals.io/message/111312#111342
> * https://externals.io/message/111312#111354
>
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]



-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

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

Re: [PHP-DEV] [RFC] [Vote] PHP namespace policy

[Larry Garfield]

On Sun, Jul 26, 2020, at 11:24 AM, Larry Garfield wrote:
> The vote on the PHP namespace policy is now open:
> 
> https://wiki.php.net/rfc/php_namespace_policy
> 
> Usual rules, 2/3 required for passage.  Vote will be open until 9 August.

The vote has been closed.  Final results:

Yes: 13
No: 17

The RFC has not passed.  Thank you to those that participated.

I neglected to include a "why not" section in the vote (my fault), so I would 
ask for those who voted no, Why?

1) I don't believe we should have a policy on this at all.
2) We should explicitly have a policy to only ever use the global namespace.
3) We should have a namespace policy, but I didn't like some detail of this 
one.  (Please explain.)
4) Other (please explain).

Thank you for your time.

--Larry Garfield

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei  wrote:

>
> On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer 
> wrote:
>
>>
>> I have voted no because I asked a question about the ending delimiter and
>> why () didn't count. Another person asked a similar question and neither
>> of
>> us got a reply.
>>
>
> () does not count as ending symbol, because it is not required, as such
> its not an ending symbol.
>


The question asked was that _if the parentheses were made mandatory_, would
this provide the same benefits ascribed to the other syntaxes?

To avoid repeating myself, here are the previous posts where I elaborated
on this question:

* https://externals.io/message/111312#111342
* https://externals.io/message/111312#111354


Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 10.08.20 15:08, Benjamin Eberlei wrote:

() does not count as ending symbol, because it is not required, as
such its
not an ending symbol.

The point Andreas Leathley makes in the discussion thread about new Foo not
having an end symbol demonstrates exactly the opposite point he was trying
to make, because the new statement itself has to end with a semicolon:

new Foo();
new Foo;

A statement has an ending symbol semicolon.


While I don't know the exact internal semantics of PHP, according to my
grasp of the language the new keyword does not need a semicolon at the
end - it can be part of any expression, like "new Foo(new Bar);".
According to the PHP manual
(https://www.php.net/manual/en/language.basic-syntax.instruction-separation.php)
instructions in PHP need to be terminated with a semicolon, while "new"
as a keyword has no special requirement about a starting or ending
delimiter.

The point I was trying to make was that new and attributes have the same
requirements in that they both need a class name and then optionally
arguments for the constructor to that class, so they are both narrow in
terms of what they do, attributes even more so than new, which reduces
the helpfulness of delimiters as you cannot define arbitrary
instructions in attributes - it always starts off with a class and then
any possibly more complex instructions will be in the arguments, and
those are enclosed by ().

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:

> I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
> 
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> 
> The first vote is a vote to say that you have an opinion about attribute
> syntax. Make sure to read up on the discussion on the mailinglist if you
> haven't done so yet.

I voted "No", as the primary premise for this RFC is fundamentally flawed:

> The main concern is that @@ has no ending symbol and it's inconsistent
> with the language that it would be the only declaration or statement
> in the whole language that has no ending termination symbol.

As I pointed out in the discussion thread, this simply is not the case.
Attributes are not standalone declarations or statements, but modifiers
that always come before a declaration and add metadata to it. This
is consistent with visibility modifiers and type declarations (which
are not necessarily a single word):

# declaration modifiers do not have end/grouping symbols like this
@[MyAttr([1, 2])]
[public] function foo(@[Deprecated] [int|float] $bar) {}

# this is more consistent:

@@MyAttr([1, 2])
public function foo(@@Deprecated int|float $bar) {}

> The second vote is an STV vote.
> 
> In STV you SHOULD rank *all* choices, but don't pick the same one more
> than once, as that will invalidate your vote.
> 
> Please have a objective look at the table
> (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> don't just go by asthetics.

I find this table to be unfortunately incomplete. E.g. why doesn't it
bold the number of required characters for @@, since this is one of
its advantages? And why is "Allows Grouping" marked as an advantage
for the other three syntaxes? Grouping adds implementation complexity,
leads to unnecessary diff noise, and is rarely more concise than @@ in
real-world use cases.

I also find it concerning that the RFC doesn't have an example for each
consideration showing how one syntax addresses it better than another.
For example, the Shorter Attribute Syntax RFC showed potential nested
attributes and how @@ would support them more cleanly, but this RFC
fails to mention them anywhere.

Finally, while the table mentions that each syntax other than <<>> has
a BC break, I think it's just as important to consider the *size* of
the breaking change. #[] and @[] are larger BC breaks than @@ since
they break useful syntax:

// with #[]
#[x] code like this would break
$val = ['new value']; #['old value'];

// with @[]
$x = @[foo(), bar()]; // this code would break

Both of these are useful patterns, and I'm not convinced that breaking
them is justified. Shouldn't there be a Backward Incompatible Changes
section in the RFC with these examples?

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer 
wrote:

> On Mon, 10 Aug 2020 at 10:15, Rowan Tommins 
> wrote:
>
> > I am not a fan of the @@ syntax, and respect what you're trying to do
> with
> > this RFC, but am disappointed you haven't engaged with those of us who
> said
> > that the RFC needs more detail. There is simply not enough information in
> > that table to "have an objective look", and the only other text in the
> RFC
> > makes a vague assertion about the lack of ending symbol which I still
> don't
> > understand the significance of.
> >
>
> I have voted no because I asked a question about the ending delimiter and
> why () didn't count. Another person asked a similar question and neither of
> us got a reply.
>

() does not count as ending symbol, because it is not required, as such its
not an ending symbol.

The point Andreas Leathley makes in the discussion thread about new Foo not
having an end symbol demonstrates exactly the opposite point he was trying
to make, because the new statement itself has to end with a semicolon:

new Foo();
new Foo;

A statement has an ending symbol semicolon.

Yes you can argue an attribute is metadata like "public" or "static" and
they don't have start and ending symbols either. But they are also *single*
words without special chars, as such much easier to distinguish.

The difference is also apparent in another fact: Visibility keywords are
just boolean flags on Reflection, Attributes have their own Reflection
object, they represent much more. They shouldn't be mixed up with keywords.

PHP is a language where most language constructs have ending delimiters.

- Statements end in Semicolon
- Function/Class/Method declarations end with a block closed by }
- Argument lists end with )
- Docblocks end with */
- Comments always end with EOL (the distinction here being its a single end
symbol, not ambiguous)

As such for language consistency it would be better for Attributes to be
enclosed by syntax, having a start **and* and ending symbol.


> Peter
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Markus Fischer]

On 10.08.20 13:32, Jordi Boggiano wrote:

https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c


This is really really useful!

However I suggest to look at the raw text rather, because the 
highlighting is unaware of the syntax and may bias "how it feels to look 
at it" (*):


https://gist.githubusercontent.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c/raw/ccb612d2547c99fe69d1bf09138efae22b956b37/attributes.php

Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>` 
in fact is the most "unreadable" version to me because duplicate 
occurrence of a single character somehow creates a noise _for me_,


I don't feel eligible to have a vote, but based on that and certainly 
aware IDEs in the future will help with this, I would vote for 
_anything_ not duplicating characters, i.e. favoring `#[]` or `@[]`


:-}

- Markus

(*) Apologies for lack of words trying to describe my thoughts

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 11:16 AM Rowan Tommins 
wrote:

> On Mon, 10 Aug 2020 at 09:41, Derick Rethans  wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> > [...]
> >
> > Please have a objective look at the table
> > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> > don't just go by asthetics.
> >
>
>
> Hi Derick,
>
> I am not a fan of the @@ syntax, and respect what you're trying to do with
> this RFC, but am disappointed you haven't engaged with those of us who said
> that the RFC needs more detail. There is simply not enough information in
> that table to "have an objective look", and the only other text in the RFC
> makes a vague assertion about the lack of ending symbol which I still don't
> understand the significance of.
>
> If I had a vote, I would vote "No" in the primary vote, not because I think
> the current syntax is perfect, but because I don't think this RFC makes a
> good case for a revote, and strongly suspect it will just be another beauty
> contest.
>

I am sorry this was a misunderstanding between Derick and I. I had worked
on the more detail already, but we had a miscommunication about updating
the RFC. I add my notes in a few minutes, sorry :-(

>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jordi Boggiano]

On 10/08/2020 10:41, Derick Rethans wrote:

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting



Here is a more detailed comparison of how this would look like in real 
use, adapted from some basic doctrine and symfony validation annotation 
I got somewhere:


https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c

I think something like this would belong in the RFC. I find that the 
grouping "feature" does not help that much, it's kinda hard to grasp 
what's going on. Proper syntax highlighting would surely help but still.


You may argue it's comparing in terms of looks, but as others have said 
I find it hard to compare them in other terms as the pros/cons listed in 
the RFC have a very limited impact for the most part, so yeah I feel 
like looks and readability should be at least somewhat taken into 
account too.


Best,
Jordi

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

Re: [PHP-DEV] Null-safe property access in interpolated strings

[Philip Hofstetter]

Hi,

On Sun, Aug 9, 2020 at 8:34 PM Jordi Boggiano  wrote:

> Can't say I'm big on interpolation but I'd definitely expect this to
> work because why not?

A reason why not is because it will break backwards compatibility with
existing (though admittedly unlikely) code which also can't be fixed
by easy search and replace:

$foo = "gnegg";
echo "$foo?->bar()"

would be fine in PHP < 8 and would blow up with `Uncaught Error: Call
to a member function bar() on string` with this change.

I'm not saying this is a problem because code like this is unlikely to
be written, but it *is* a BC break.

Philip

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

Re: [PHP-DEV] Null-safe property access in interpolated strings

[Nikita Popov]

On Sun, Aug 9, 2020 at 8:34 PM Jordi Boggiano  wrote:

> On 09/08/2020 00:17, Sara Golemon wrote:
> > Do we expect this to work?
> >
> > $foo = new stdClass;
> > $foo->bar = "Hello";
> > echo "$foo?->bar world\n";
> >
> > Because at the moment it doesn't: https://3v4l.org/nLv3l
> >
> > -Sara
>
> Can't say I'm big on interpolation but I'd definitely expect this to
> work because why not?
>
> I think if it can be reasonably fixed it probably would make sense for
> consistency and WTF-avoidance if anything.
>
> Best,
> Jordi
>

Agree. I don't think the question of whether it is useful should come into
this, it's a matter of language consistency. There could be some leeway
here if we say that we have plans to deprecate the "$x->y" syntax in the
future anyway and don't want to extend it anymore -- but I don't believe we
have such plans at the present time.

Nikita

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

[Christoph M. Becker]

On 10.08.2020 at 10:35, Derick Rethans wrote:

> On Fri, 7 Aug 2020, Theodore Brown wrote:
>
>> - Used by other language:
>> - This is listed as an advantage for `#[]` and `<<>>`. However, the table
>> fails to point out that Hack is migrating away from `<<>>` to `@Attr`.
>
> It can only do that because they are removing @ as the shut up operator,
> which ain't going to happen in PHP.

If we could afford the luxury of removing the @ operator, would you
prefer @ for attributes?

--
Christoph M. Becker

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

On Mon, 10 Aug 2020 at 10:15, Rowan Tommins  wrote:

> I am not a fan of the @@ syntax, and respect what you're trying to do with
> this RFC, but am disappointed you haven't engaged with those of us who said
> that the RFC needs more detail. There is simply not enough information in
> that table to "have an objective look", and the only other text in the RFC
> makes a vague assertion about the lack of ending symbol which I still don't
> understand the significance of.
>

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither of
us got a reply.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Mon, 10 Aug 2020 at 09:41, Derick Rethans  wrote:

> I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
>
> [...]
>
> Please have a objective look at the table
> (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> don't just go by asthetics.
>


Hi Derick,

I am not a fan of the @@ syntax, and respect what you're trying to do with
this RFC, but am disappointed you haven't engaged with those of us who said
that the RFC needs more detail. There is simply not enough information in
that table to "have an objective look", and the only other text in the RFC
makes a vague assertion about the lack of ending symbol which I still don't
understand the significance of.

If I had a vote, I would vote "No" in the primary vote, not because I think
the current syntax is perfect, but because I don't think this RFC makes a
good case for a revote, and strongly suspect it will just be another beauty
contest.

Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

Hi,

I've just opened the vote to make sure we don't make a terrible mistake 
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute 
syntax. Make sure to read up on the discussion on the mailinglist if you 
haven't done so yet.

The second vote is an STV vote.

In STV you SHOULD rank *all* choices, but don't pick the same one more 
than once, as that will invalidate your vote.

Please have a objective look at the table 
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and 
don't just go by asthetics.

The vote ends August 23, 24:00 UTC.

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] Shorter Attribute Syntax Change RFC 0.2

[Derick Rethans]

On Fri, 7 Aug 2020, Theodore Brown wrote:

> On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans  wrote:
> 
> > On Fri, 7 Aug 2020, Theodore Brown wrote:
> > 
> > > 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 was very *specifically* voted for:
> > https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes
> 
> It was specifically voted for the `<<>>` syntax, with the explicit 
> qualification that "This feature would be superseded by any other RFC 
> getting accepted that changes the syntax." This is exactly what 
> happened when the Shorter Attribute Syntax RFC was accepted.

But there wasn't a *specific* vote to remove that, like there was one to 
enable it.

> > You still haven't addressed any of the deficiencies that the other
> > alternatives don't have:
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal
> 
> I'm not sure which deficiencies you mean, but let's briefly go
> through the table in the RFC to make sure nothing has been missed:
> 
> - Number of required Characters:
> - `@@` has the advantage here.

But @@ takes up 94 pixels, whereas #[] only takes up 77 (and @[] 83), so 
clearly better.

> - Has End Delimiter:
> - This isn't clearly a pro or a con in itself.

But you haven't said why it is better that *not having it* is better.

> - Allows Grouping:
> - As discussed before, `@@` has the advantage of being equally
> concise without this added complexity.

I have no idea what that means.

> - Forward Compatibility in PHP 7:
> - This is at best a temporary benefit of `#[]` which will be
> irrelevant in a few years, at worst a source of confusion and bugs
> when code intended for PHP 8 runs on PHP 7 with different results.

But it helps now, maybe only a little, but it does.

> - Breaks BC of valid PHP 7 code:
> - All syntaxes but `<<>>` technically have a BC break. There really
> should be a separate line in the table for "Breaks useful syntax",
> since `#[]` and `@[]` have this deficiency, but `@@` does not.

@[] and #[] don't break "useful syntax" either.

> 
> - Used by other language:
> - This is listed as an advantage for `#[]` and `<<>>`. However, the table
> fails to point out that Hack is migrating away from `<<>>` to `@Attr`.

It can only do that because they are removing @ as the shut up operator, 
which ain't going to happen in PHP.

> Furthermore, while `#[]` has the same start/end symbols as Rust, the rest
> of the grammar/semantics vary significantly. E.g. these are valid Rust
> attributes (see https://doc.rust-lang.org/reference/attributes.html):

I've never said that it has the same semantics, only that the syntax is 
familiar. It still stands that nothing uses @@.

> - Familiar with Docblock Usage:
> - `@@` has the advantage here once more.

@@ isn't used in docblocks.

> - Tokens used:
> - This isn't clearly a pro or con in itself.

[citation required]
 
> - Changes the lexing of **remaining** tokens:
> - This is apparently a con for `#[]`.

That's why there is @[] now, which is a compromise, something that you 
don't seem to be interested in caring about.

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] ZEND_ENGINE_4 define?

[Nikita Popov]

On Mon, Aug 10, 2020 at 7:57 AM Philip Hofstetter <
phofstet...@sensational.ch> wrote:

> Hello,
>
> I'm currently looking into porting some extensions (both internal and
> public) to PHP 8 while still keeping support for PHP 7 (for the public
> ones) and PHP 5.6 (don't ask :-().
>
> In many cases, I've been using the ZEND_ENGINE_3 define to handle the
> PHP 5/7 difference.
>
> Now, the Zend Engine version seems to have been increased to 4 (which
> feels warranted given the zval* to zend_object* changes for object
> handlers), but ZEND_ENGINE_3 is still defined whereas there's no
> ZEND_ENGINE_4.
>
> Is this something that might change or should I just use
> PHP_VERSION_ID comparisons to deal with the zval* to zend_object*
> changes?
>
> Philip
>

I would recommend using PHP_VERSION_ID.

I have no idea why we have the ZEND_ENGINE_3 constant, but it seems like a
pretty bad idea. Now that we are at ZE 4, should we drop that constant --
and break all the code using it? Chances are that code guarded by
ZEND_ENGINE_3 is also needed on all versions of ZE going forward, not just
ZE 3 in particular. I think we should just leave teh ZEND_ENGINE_3 define
around, but make sure not to introduce a new one of that kind.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Import of variables

[Manuel Canga]

Hi, Internals,


Thanks, Marco and also to Rowans, Josh, David and Tyson

I'll use IIFE in order to avoid global conflicts.

Regards

  En lun, 10 ago 2020 02:16:06 +0200 Marco Pivetta  
escribió 
 > Hey Manuel,
 > 
 > 
 > 
 > 
 > On Sun, Aug 9, 2020, 11:02 Manuel Canga  wrote:
 > 
 > > Hi Internals,
 > >
 > > I'd like to open up a discussion around the implementation of a new
 > > functionality: 'import of variables'.
 > >
 > > This functionality would allow to create a new  'use vars' keyword in
 > > order to can use( or cannot use )  global variables in local scope( of
 > > current file ).
 > >
 > > I think the best is a example:
 > >
 > > ```php
 > >  >
 > > $a = 1;
 > > $b = 2;
 > > $c = 3;
 > >
 > > include __DIR__.'/without_import.php';
 > > include __DIR__.'/all_import.php';
 > > include __DIR__.'/none_import.php';
 > > include __DIR__.'/some_vars.php';
 > > include __DIR__.'/global_in_function.php';
 > > ```
 > >
 > > ## without_import.php
 > >
 > > ```php
 > >  >
 > > echo $a; //1
 > > echo $b; //2
 > > $c = 'any value'; //replace value in global var
 > > ```
 > >
 > > ## all import.php
 > >
 > > ```php
 > >  >
 > > use vars all;
 > >
 > > echo $a; //1
 > > echo $b; //2
 > > $c = 'other value'; //replace value in global var
 > > ```
 > >
 > > ## none_import.php
 > >
 > > ```php
 > >  >
 > > use vars none;
 > >
 > > echo $a; //Warning: undefined var $a
 > > echo $b; //Warning: undefined var $b
 > > $c = 'other value'; //assign value to local var
 > > ```
 > >
 > >
 > > ## some_vars.php
 > >
 > > ```php
 > >  >
 > > use vars $a, $c, $d; //Warning: undefined var $d
 > >
 > > echo $a; //1
 > > echo $b; //Warning: undefined var $b
 > > $c = 'a value'; //replace value in global var
 > > ```
 > >
 > > ## global_in_function.php
 > >
 > > ```php
 > >  >
 > > use vars $a, $c;
 > >
 > >
 > > function hello() {
 > > global $a, $b, $c;
 > >
 > > echo $a; //1
 > > echo $b; //null.
 > > $c = 'end value'; //replace value in global var
 > > }
 > >
 > > hello();
 > > ```
 > >
 > >
 > > In a project with a lot of global vars( like WordPress ) this
 > > functionality avoids conflicts and easy replacements of values in main
 > > global vars.
 > >
 > 
 > This looks like what IIFE do already (you can use them today):
 > 
 > ```php
 > 
 > require 'something/with/side/effects.php';
 > 
 > (static function () use ($a, $b, & $c) : void {
 > echo $a; //1
 > echo $b; //Warning: undefined var $b
 > $c = 'a value'; //replace value in global var
 > })();
 > ```
 > 
 > You can use this right now, and it has the advantage of reporting any
 > missing symbols right at the time at which the closure is declared.
 > 
 > I tend to use IIFE all the time in procedural code, since they prevent
 > leaking state into globals 
 > 
 > >
 > 

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