[PHP-DEV] RE: [EXTERNAL] Re: [PHP-DEV] Microsoft Support of PHP on Windows

[Dale Hirt via internals]

Hi Sara,

Thank you for responding back.

We have tooling in place to allow for building and testing.  We did build the 
latest bits on 8.0 to test some things, but we are not moving forward with any 
more builds.

Please let me know how we can help with the transition as it moves forward.

Thank you for your time,

Dale

From: Sara Golemon 
Sent: Thursday, July 9, 2020 1:01 PM
To: Dale Hirt 
Cc: PHP Internals ; php-wind...@lists.php.net; 
internals-...@lists.php.net; Greg Arnits ; Antoni 
Hathaway 
Subject: [EXTERNAL] Re: [PHP-DEV] Microsoft Support of PHP on Windows

On Thu, Jul 9, 2020 at 1:48 PM Dale Hirt via internals 
mailto:internals@lists.php.net>> wrote:
My name is Dale Hirt and I am the project manager for PHP inside Microsoft.
We are not, however, going to be supporting PHP for Windows in any capacity for 
version 8.0 and beyond.

Hi Dale!
First, let me convey all our appreciation for the work Microsoft has put into 
supporting PHP on Windows over the years.  Thank you also for letting us know 
in advance to not expect 8.0 builds.  I guess this decision must have only been 
made very recently since 8.0.0alpha1 and alpha2 builds were produced already.

I won't say I'm not bummed, of course.  Nevertheless, y'all gotta do what you 
gotta do.  I'm sure we can work out an alternative by the end of the year.

All the best,
-Sara Golemon (PHP 8.0 Release Manager)

Re: [PHP-DEV] Microsoft Support of PHP on Windows

[Sara Golemon]

On Thu, Jul 9, 2020 at 1:48 PM Dale Hirt via internals <
internals@lists.php.net> wrote:

> My name is Dale Hirt and I am the project manager for PHP inside
> Microsoft.
>
> We are not, however, going to be supporting PHP for Windows in any
> capacity for version 8.0 and beyond.
>

Hi Dale!

First, let me convey all our appreciation for the work Microsoft has put
into supporting PHP on Windows over the years.  Thank you also for letting
us know in advance to not expect 8.0 builds.  I guess this decision must
have only been made very recently since 8.0.0alpha1 and alpha2 builds were
produced already.

I won't say I'm not bummed, of course.  Nevertheless, y'all gotta do what
you gotta do.  I'm sure we can work out an alternative by the end of the
year.

All the best,
-Sara Golemon (PHP 8.0 Release Manager)

[PHP-DEV] Microsoft Support of PHP on Windows

[Dale Hirt via internals]

Hello PHP Internals,

My name is Dale Hirt and I am the project manager for PHP inside Microsoft.

We currently support PHP with development and build efforts for PHP 7.3, and 
PHP 7.4.  In addition, we help with building PHP 7.2 on Windows when security 
fixes are required..

However, as PHP 8.0 is now ramping up, we wanted to let the community know what 
our current plans are going forward.

We know that the current cadence is 2 years from release for bug fixes, and 1 
year after that for security fixes.  This means that PHP 7.2 will be going out 
of support in November.  PHP 7.3 will be going into security fix mode only in 
November.  PHP 7.4 will continue to have another year of bug fix and then one 
year of security fixes.  We are committed to maintaining development and 
building of PHP on Windows for 7.2, 7.3 and 7.4 as long as they are officially 
supported.  We are not, however, going to be supporting PHP for Windows in any 
capacity for version 8.0 and beyond.

Please feel free to direct any questions to me at 
daleh...@php.net.

Dale Hirt
Service Engineer
425-704-8109
 [cid:image001.png@01D655E5.E1A44800]
Nothing can stop a team.
Work remotely with Microsoft 
Teams.

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Marcio Almada]

Hi,

>
> Hey Marcio,
>
>>
>> Hi
>>
>> >
>> > Re casting - In the previous thread the following concern was presented 
>> > and I don’t know enough about that area to respond effectively: "I'd 
>> > endorse avoiding object-to- casts via cast operations: they are a 
>> > good source of bugs. My rationale for the discouragement of magic cast 
>> > methods is explained with some code examples at 
>> > https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229”
>> >
>>
>> Frankly this is something subject to personal opinions and will change
>> over time according to community shifts.
>>
>
> Not sure what's "subject to personal opinions" in the objective bug exposed 
> in the snippet above?
>

So there is a bug in a contrived code snippet therefore casting is a
universal bad practice?
It's at least a huge stretch. Some might say your bad practice was
actually using `null` ;)

> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/

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

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Marco Pivetta]

Hey Marcio,

On Thu, Jul 9, 2020 at 7:49 PM Marcio Almada  wrote:

> Hi
>
> >
> > Re casting - In the previous thread the following concern was presented
> and I don’t know enough about that area to respond effectively: "I'd
> endorse avoiding object-to- casts via cast operations: they are a
> good source of bugs. My rationale for the discouragement of magic cast
> methods is explained with some code examples at
> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
> ”
> >
>
> Frankly this is something subject to personal opinions and will change
> over time according to community shifts.
>
>
Not sure what's "subject to personal opinions" in the objective bug exposed
in the snippet above?

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Rowan Tommins]

On Thu, 9 Jul 2020 at 18:14, Derick Rethans  wrote:

> On Thu, 9 Jul 2020, Rowan Tommins wrote:
>
> > And yet we have repeatedly had discussions about whether this or that
> > feature should or shouldn't be prefixed with a namespace. If you think
> > the correct answer to "when should we use the PHP\ prefix?" is
> > "never", I urge you to put forward an RFC making that the policy.
>
> That is already the policy:
> https://www.php.net/manual/en/userlandnaming.rules.php
>
> Specifically "PHP owns the top-level namespace but tries to find decent
> descriptive names and avoid any obvious clashes"
>


That is not the same thing at all. That states that PHP may use the global
namespace; it doesn't say it will never use any other namespace.

And https://www.php.net/manual/en/language.namespaces.rationale.php says
essentially the same thing about the PHP\* namespace:

> The Namespace name *PHP*, and compound names starting with this name
(like *PHP\Classes*) are reserved for internal language use and should not
be used in the userspace code.


At the very least, it is not universally accepted that the policy is never
to use the PHP namespace, or we wouldn't keep having this conversation.

So, again, if anyone thinks that the policy should be to never use the PHP\
namespace prefix, please put it to a vote. (I'm quite tempted to do it
myself from a position of Devil's Advocate.)


Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Marcio Almada]

Hi

>
> Re casting - In the previous thread the following concern was presented and I 
> don’t know enough about that area to respond effectively: "I'd endorse 
> avoiding object-to- casts via cast operations: they are a good source 
> of bugs. My rationale for the discouragement of magic cast methods is 
> explained with some code examples at 
> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229”
>

Frankly this is something subject to personal opinions and will change
over time according to community shifts.

I think the main obligation of languages and runtimes is to show
consistency in their design and behavior. If somehow part of the
community wants to enforce that "casting is a bad practice" (because
IDE support or whatever valid reason in our current decade) it's ok.
But making the language behave differently for each casting scenario
actually makes it harder for userland to apply the good practices of
the moment consistently.

> I concur with the Stringable mention - thank you for that - I have updated 
> based on this feedback: https://bit.ly/php-0001
> Given that the goal would be to have the class be used in place of a bool 
> everywhere, I would think we would need to make it cast-able to a bool, yeah?
>

Yes, precisely.

Thanks,
Márcio

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

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Derick Rethans]

On Thu, 9 Jul 2020, Rowan Tommins wrote:

> And yet we have repeatedly had discussions about whether this or that 
> feature should or shouldn't be prefixed with a namespace. If you think 
> the correct answer to "when should we use the PHP\ prefix?" is 
> "never", I urge you to put forward an RFC making that the policy.

That is already the policy: 
https://www.php.net/manual/en/userlandnaming.rules.php

Specifically "PHP owns the top-level namespace but tries to find decent 
descriptive names and avoid any obvious clashes"

cheers,
Derick

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

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Larry Garfield]

On Thu, Jul 9, 2020, at 6:55 AM, Rowan Tommins wrote:
> On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd  wrote:
> 
> > On Tue, 7 Jul 2020 at 15:47, Larry Garfield 
> > wrote:
> > >
> > > This has reached the 2 week mark, but there's not been much discussion.
> >
> > Unless I'm having a massive reading failure, this RFC has been
> > announced twice. And feedback was provided before:
> >
> > https://externals.io/message/109646#109647
> > https://externals.io/message/109646#109648
> 
> 
> 
> 
> It seems that, although still labelled version 1, the RFC has been
> substantially rewritten since that discussion.

Yes, based on the discussion in chat that resulted in actual guidelines, we 
mostly rewrote the whole document.  I've no idea what the rules are around new 
version numbers of RFCs that haven't been up for a vote yet.

> > From the RFC:
> > > Every new global class, however, creates a potential namespace collision
> > > with existing user-space code and thus a potential for backward
> > > compatibility breaks.
> >
> > This doesn't appear to be an actual problem for the PHP ecosystem.
> >
> > The vast majority of code in libraries is in namespaces, which avoids
> > there being a problem that needs addressing.
> 
> 
> And yet we have repeatedly had discussions about whether this or that
> feature should or shouldn't be prefixed with a namespace. If you think the
> correct answer to "when should we use the PHP\ prefix?" is "never", I urge
> you to put forward an RFC making that the policy.
> 
> 
> > Rather than having more rules (quite a few of which I don't agree
> > with), time and effort would be better spent on reviewing code and
> > using features before releases e.g. to avoid situations like the FFI
> > api being difficult to use.

Which guidelines in particular bug you, and why?

> 
> This is pure whataboutery; the idea that reading a few naming conventions
> will be such a burden that somebody would have no time to review a feature
> is frankly ridiculous. Nor will the lack of a naming convention mean that
> no time needs to be spent naming things - quite the contrary, it will mean
> more time is wasted debating every case.
> 
> It's worth stressing that naming conventions are not new - we've had them
> for global functions for many many years. We may talk about "putting things
> into namespaces", but PHP's namespaces really are just names, so this RFC
> could easily be called "update naming conventions for classes".


I fully agree that this is a why-not-both-girl.gif situation.  If anything, 
reducing the time that gets spent asking "*now* can we start using a 
namespace?" will open up more time for people to actually review APIs.  
Although since those are two very different mindsets I doubt that there will be 
any impact on available-API-review time either way.  (That said, more time and 
attention paid to developing clean, usable APIs can only benefit PHP.)

--Larry Garfield

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

Re: [PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

[Peter Bowyer]

On Thu, 9 Jul 2020 at 14:52, Benjamin Eberlei  wrote:

> For me the RFC vote should be "allow to dcelare return types on
> constructors/destructors?", then people *can* declare void, but *can* also
> declare other things, but nothing *must* be done. Then it becomes a
> question of coding styles enforcing "void" for all constructors of a
> project for example. I would vote Yes on that.
>

Isn't this close to what the second vote "Allow void return type on
constructors/destructors?" does?

My understanding is that a "Yes" on this vote will:
1. Allow you to omit a return type (and therefore return whatever you want)
2. Explicitly add void return type

This doesn't do exactly what you ask for (to add any return type) but to me
is close enough; as these are meant to be void according to the PHP docs,
having it as the only explicit return type makes sense to me.

Peter

[PHP-DEV] PHP 7.3.20 Released

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.20.  This is a security release impacting the official Windows
builds of PHP.

For Windows users running an official build, this release contains a
patched version of libcurl addressing CVE-2020-8159.

For all other consumers of PHP, this is a bug fix release.

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

For source downloads of PHP 7.3.20 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:
cURL sec advisory:<

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.20.tar.bz2
SHA256 hash:
c6ed7894911acfe075381c01b07745d92e9259fac510a849f742edb6b95c89de
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8EK/oMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2S4YP/i9GiSHcvrhl0QGag8+fyT/HSdn09Z6n19on5NMB
XjjhttphYVo2B8qoHxXCGT8zQ/Tb21U7lkTs8gYSCFJtES0QAk8JnApMmBTftLuX
uczF29JX5xbL1uLRpAQ7nXUpNFULANz223xfJDx+lgyV3r1m3J+djSkj/eueV32X
1vivMeLoEtVxGtNJoGpL8FBUz2ryDuGuC8wMZA5mgwSVwfcyEyOfn/PKTKzK+Rsu
/fAIwdWJyL1mM4vrsscW3f7acpGN19vgSqy/iMAok7bA1NeGYWhN80dbXA4Ms91M
3t0RtQIPwlhGYQO5SnxGFX8Oh0EJetoOihRq5r6BxgCJbCaiZcNSaCG/xa7ontuy
yqFOHFarAUXJUH+EJl1V2NQ742qNY2NHoIIXdpZBa7iQGHnHW/wIVgQpIfAVy7/d
R6qIjgM/V6m1a7l8byvrS5ih5c1YKuxgGde9926oA029P6cEeMWS9PtWQ7bNyEJI
DlDwev5MHrOwBg27xTVteWWJXY563NtW7w+VoOVjYU3R3LMCru0M3dAOGZzakL/S
uGogbed7+frdlUh9w89E4owF3nA7gEBpynTrennEUAzQSN7EEi2L3CtvpLrMspW+
kL/BzSNu9J3o2c0mt5YC7sE8phuGho7PLP/RtnJsJpabhmxITSF2SfEEnb9MRkCG
fVKZ
=Xgc8
-END PGP SIGNATURE-


php-7.3.20.tar.gz
SHA256 hash:
d0579b8a6bcdd5e1ae334d83261f2389b0d3d4fd54cc808e20a5031121f97d87
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8ELAkMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2/G0P/0MxN7hnN9r/rEr8AkHh5H8DrxE5Z1KidCYBuy/r
+zKV1RT6GeQuR4gtJij1eOUDPLJtV02Dg7rIrH18GLqEwxH7eL6oBiC8bOePipWZ
hPW8pn7okm5GoJzpVVicQq1Qc7SCVtBdd/XuQKt082ldgYnyxU1u3BNOA8FFh92G
Aa4GRSCMXsKcTaUNMm5TZthylii4O61x1iHzY85r6L4sUy2SuQrw8w6FNaOtQmP6
6DYXAODdfsbvSNF8keqaayXz/RmN0zHTqivrb0TzdAVK0mAGcpF/ZQN5xquAuB66
dUNwrEG8LSys7/1Lcof4zC7RCmEhhwt3XEd9iJoFsx5YNhlPn/ny2crjDRL9Nt22
30O3I+7GUD5ZxhMaKSl0bhSfExYK/cyYyOq4FK2jF8NlcUDuClNM6sgUzPgLjprc
B7hPiKe1iT45wCNfDq3rrmM7eYHrUKy13AAZDIB/ytGe89JiOiPpJKM9wfyPh+Mg
xbaJaugA1GazIZp4iEQZDfRavj013Yh73yBRDCIvzuKis/+MQ3b2GYdS4Uu86kRj
ntH+W3KffwaT7poK8dXwDXlTL5p0pJ+himzh2S5rGbDT0cgYVM6UOPov2AaiQUrf
Mc4CYI6GB0gSgl/dzYQ/7bCvdP/tT5ul75TAT7N8U5Grz4SCHQbo4ZMmKyI/EiM/
ELLD
=1DBT
-END PGP SIGNATURE-


php-7.3.20.tar.xz
SHA256 hash:
43292046f6684eb13acb637276d4aa1dd9f66b0b7045e6f1493bc90db389b888
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl8ELAkMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y240EP/2Ed4Fa6u+0kYDg0d0Tn0E9zjJTI3oIX64kvUnA9
368L0AzCpCEHMZoE36oeLHs+pmqm2Irz2FrjvwnmXlKbf7k9iZsgo/IZxTesetE4
wBmzGZCWEgEcpUTHav/scejEysD70GbzBo3wpIzIps3D+4wcMFXYSpygFiEtMGiM
MqNnTn+Q/i8krNIGtuV20RnuGkzDedogUb99B1E0LjiuS9Lq/obFeWGWnNMsgYlv
TEPxcMgqsglovXZd3Z2tdAqQ34A89gdOkK97oUDeBrLJfJabgFrCprMlOWiECkNs
VuKKqiHSQOcPoebpKzwYh0rsLD3glIW7MXU1koyXFS2QTiLNsaUTv+8vxWnr6JNg
9nuZfD2OgI0gSLMbpjvTBLJFIUA43/Sp/iQAlA1sQJZXnOSi+xjkqgtNw8hnwURT
lDrCnCqcBb0L11aDamBVE4E/2UVTg7bRRxFrMRnsQtr6SqXO/QBbhnpyHQLsnBd/
tcGDZw7uSTIoAoy6PpIWg70E5lDArZcHHJ51IXfCvTMPSx0IkzdNUg1VOeUzlHtX
1zR1Ms2Umr6EWvwC9krzow16iSty3pUfzs57qVBYAt5jS776qIvHmo+kIMcYQzki
X4sn3IQntksLevOh+RNIuSWoLgtmNpCc8TMfhHEU2tapoLxgaNaHbxqNAv7cNqL0
/wRc
=zju5
-END PGP SIGNATURE-

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

[PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Nikita Popov]

On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov  wrote:

> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd
> like to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>

I have reduced the scope of this RFC to handle just the issue of namespaced
names, without touching any other reserved keyword restrictions. As the
discussion shows, those are trickier, with more cases of perceived
ambiguity that may need to be mitigated.

As this proposal is now a prerequisite for
https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
disturbing number of people that they might vote against this proposal, not
because they disagree with it, but because that would prevent the adoption
of the @@ attribute syntax. I'm not sure what to do about that...

Regards,
Nikita

Re: [PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

[someniatko]

> I think going from forbidding
> return types on ctors to requiring them to be void is one step to far.

I am afraid you've slightly misunderstood the intention of this RFC.
It is proposed that it is impossible to return anything from the
constructor, not that you have to add ": void" to it.

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

[PHP-DEV] PHP 7.4.8 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.8. 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.8 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.8.tar.gz
SHA256 hash: 649f6bcdb60dc38d5edd7f3a7b2905d15d88c1d13e40307e8972ede347cea6ba
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8G3GIACgkQkQ3rRvU+
oxJWRg/+MjrdZyLzJtCI77hkcWtLjmbeYVIhTmSTR8zySJokCe5e8jqVPS/AM0gX
vI1BduZnkoKAg8eP2JU98/Kl5nnplK9G1TZ3FChqKrpnttEAEm4HdZB44xBXbUeh
EIBlidXls9cPkjtWhYyCqaahcElYrJuzymuLCm/JOfO+xKlIqmq4odLtlM5aBeqK
nhWjYxGbXocw3H38U4hUGa3AkI1vY28me49R/hse76g58YheOZI4oJUPLMM5io5a
QEo52UgcMrZxpUbkWYQlfgwDlUFpA8o1GBX1A2gebmCbPxMoeS+FjggOyAjegPcB
KeinQraOui6OuNXk03nL0ptcGuY8dQceitJmdICcH4CZ0TDXQAYxcpjBxRZsKtBX
L7ecSMUITkBVnEupug753542Q3ppdtzgA5Vdj471jTul6d4AWdCNJPH7d9ZwU6yG
HYqJ6/cKmpieI6XSzdMzZnL8epZvRmtDAHLceWUtTwKjuC16t9q3RM2YrTQSWcB9
+gAD4Atf+m8aobgzBVEbuMpP+yEj5u2XfWTbPyULXf3BU3UuhC/7JwcAW+i167oA
slftSPS3/0R6tOrPkW8otEBcW1JdWzUgl978wMTPc8S3Xe9iI/6xb/dKy798m28i
o6SxfIuMUqtrSFqqzUIYzEelW02GAhSVskObzioamGEXsMCRppU=
=pQNz
-END PGP SIGNATURE-

php-7.4.8.tar.bz2
SHA256 hash: 6a48d3a605c003b088984ceb53be5df1e698b8b35ddacadd12fe50f49c0e8062
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8G3GkACgkQkQ3rRvU+
oxK3/xAAi8QhwKDrqQLWuQLzprAx2yq20eCHTAzap2QcBOJ3xbLTN8XgIe8FU4kQ
VwzX+BE4p8aLpjqebnZoBxCU/M6Gli54r8yBnXwqcCIjXxQWK1M1RaJwDR5jlyYZ
mKY0x5NFHPzVcS3KrubC3y+dS5EqYhKP+eal5L0HU5yNVeN2mVPOdsa7UV2CDe6Q
KTUF7CHrO77l0VF6YH07n0x353xq1XToNTkYVr0uU7/l1IqdyySvg3pV94zL9q2I
1pujn9m1U2hQpcI0y6KCKnzPRGVH7Cjj04xYzWT79MKxl0H4Q2zYPUKRZrLvexZz
Wop0RLj49lrK1FlZhsUJESyXQw5LIZHNUAbTP2TthdNR4soM/A/ZTP3N1Q/BVejq
J4hG7Q6Xmzp/Bmv4BcQbpygofEs71JPVXNSUlATttHmIFOgxEijJcifxLZ56jyxL
/T6+EQV8uDQ70Ho6GaZfbMWIhz18lIWAyc5QRxRiZCBkNmSXqNMb9W/C4xqVwcux
xgbHoh8LA8F5brHNdv7g6WWwk47ogb87NNZ0U3QtdWqOTVqWjoI0nuL1kRovF5fa
PCi2uo5LoY+CADvbUwL2SB5qFO7YK8W7Y2VaS4PpgS3I5ylXnFXNY8eaPbMWqUPt
tFURvMCFQTpwKuLpjbsvoWLk8pgLz57t1MGNUeuojnmPZrq2zoc=
=96y9
-END PGP SIGNATURE-

php-7.4.8.tar.xz
SHA256 hash: 642843890b732e8af01cb661e823ae01472af1402f211c83009c9b3abd073245
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl8G3GkACgkQkQ3rRvU+
oxI9ug/+KJRhp4nHJ3M9b4P7Thb5zeM49NyhqJIDeidIKshoN0yaABrp0CGm80RC
MuIMz6+DkybZ4iCXMt8boTA6CkY4Y+E2nSNYlDYkude10zTkCmYq5yVkZB4ojMpk
04Z1+HblqCd/XaZVDwvO/IGGix7Vlm7qsAdG+MupJDIVme2xdSxqLhoDmsT29Ex+
1vwI4IRnQrniD/nheeWlh7V8+vCf38Pn5Cq4tjQyZPI6a7aXnd6+C2V+snSO9IPg
zN5g/m9jM0uvVXR4wgb8PtPIdWLkQqxol7wyOQA0/YYmNAh/ZhacFxeY0rSK95V6
CawjWGT6Fn34i40qdzOMPMy2KR5GGqdYaMB96X6vr7UVwC3QaT2theDfUduDPDVK
/ulfmT5dLmqgh7ViNb5eq9zW0DfRvSI4gUiap5XBn0vB4IbocSyB10Ld4DzmsUja
RC3EIZNziIyDTp4uKufmxcVYP6rfcPQLR81x/hGVV+wyTUBZCIR2j07VpIEqZCmL
knXkDZFBJ/jgxE9xCcEe3Xmcm2eM6jMeCxs9o3KhfA7zFwfJvYTyPYfnKSpEleYu
rLkAtjFgjilmG90AmbUiApIozehMEQ0a5yvPHDylzG1Auh4RqjgJR+NWimY0Dyq6
f39LjH7RPq88S7unBK2qmNU1Jr0VcjyOb9VioBQU2JmBKzWP41w=
=Exqa
-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

[PHP-DEV] PHP 7.2.32 Released

[Sara Golemon]

The PHP development team announces the immediate availability of PHP 7.2.32.
This is a security release impacting the official Windows builds of PHP.

For Windows users running an official build, this release contains a
patched version of libcurl addressing CVE-2020-8159.

For all other consumers of PHP, this release is functionally identical to
PHP 7.2.31 and no upgrade from that point release is necessary.

Release Announcement: http://php.net/releases/7_2_32.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.32
Signatures and Checksums:
https://gist.github.com/sgolemon/030a3c04cdc8e073bdfb96a3f70f8701

Many thanks to all contributors and supporters! Stay typesafe and wear a
netmask!

Sara Golemon, Remi Collet

Re: [PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

[Benjamin Eberlei]

On Wed, Jul 8, 2020 at 10:15 PM Benas IML  wrote:

> Hey internals,
>
> I have reopened the voting. It is going to close July 22nd, 2020. I have
> also
> added a "Why allow void return type on constructors/destructors?" section
> which
> I hope internals are going to read and consider before voting. Thanks!
>

I wanted to give a datapoint for my no vote. I think going from forbidding
return types on ctors to requiring them to be void is one step to far. Yes,
the use-cases for returning something from a constructor are questionable,
but why force something that strictly is not something the language should
care about, as it can as easily be a coding style topic.

For me the RFC vote should be "allow to dcelare return types on
constructors/destructors?", then people *can* declare void, but *can* also
declare other things, but nothing *must* be done. Then it becomes a
question of coding styles enforcing "void" for all constructors of a
project for example. I would vote Yes on that.


> RFC:
> https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
> Benas
>
> On Fri, 3 Jul 2020 at 00:12, Benas IML  wrote:
> >
> > Hey internals,
> >
> > I have opened the voting for the RFC, let's hope everything is going
> > to be smooth :). If you have any other questions, let me know!
> >
> > RFC: https://wiki.php.net/rfc/make_ctor_ret_void
> >
> > Best regards,
> > Benas Seliuginas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

[Josh Bruce]

> On Jul 8, 2020, at 12:54 PM, Marcio Almada  wrote:
> 
> Hello Josh,
> 
>> Link to working draft: https://bit.ly/php-0001 
> 
> From a type safety POV I'd prefer to have an interface available, the
> same way we did
> to the Stringable interface RFC. But I'd rather keep these engine
> affecting behaviors
> with the same magic method naming conventions and its `__` prefix.
> 
> So `implements Bool` + `function __toBool() : bool` is the only path that 
> seems
> entirely consistent with what we already have.
> 
> The draft doesn't mention (bool) casting behavior at the time I'm
> reading it, but you do
> mention the possibility. It seems necessary to me. Why wouldn't
> `(bool) $my_bool_obj`
> behave differently from `(string) $my_stringable_obj`?
> 
>> 
>> ps. If you have any feedback or information on social interactions here that 
>> might help, please do let me know, normally I would have watched for a while 
>> before putting my foot in - hopefully it doesn’t end up in my mouth. :)
> 
> 
> Thanks,
> Márcio Almada
> 

Hello Marcio,

Thank you for the input.

Re casting - In the previous thread the following concern was presented and I 
don’t know enough about that area to respond effectively: "I'd endorse avoiding 
object-to- casts via cast operations: they are a good source of bugs. 
My rationale for the discouragement of magic cast methods is explained with 
some code examples at 
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
 
”

I concur with the Stringable mention - thank you for that - I have updated 
based on this feedback: https://bit.ly/php-0001 
 
I’ve also included a “questions outstanding” section as I could imagine people 
losing threads and wanted to give a way to “get up to speed” quickly.

Given that the goal would be to have the class be used in place of a bool 
everywhere, I would think we would need to make it cast-able to a bool, yeah?

Cheers,
Josh

ps. Thank you again. I feel like every bit of feedback causes a re-write and 
iteration on the presentation. Lol

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Rowan Tommins]

On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd  wrote:

> On Tue, 7 Jul 2020 at 15:47, Larry Garfield 
> wrote:
> >
> > This has reached the 2 week mark, but there's not been much discussion.
>
> Unless I'm having a massive reading failure, this RFC has been
> announced twice. And feedback was provided before:
>
> https://externals.io/message/109646#109647
> https://externals.io/message/109646#109648




It seems that, although still labelled version 1, the RFC has been
substantially rewritten since that discussion.




> From the RFC:
> > Every new global class, however, creates a potential namespace collision
> > with existing user-space code and thus a potential for backward
> > compatibility breaks.
>
> This doesn't appear to be an actual problem for the PHP ecosystem.
>
> The vast majority of code in libraries is in namespaces, which avoids
> there being a problem that needs addressing.
>



And yet we have repeatedly had discussions about whether this or that
feature should or shouldn't be prefixed with a namespace. If you think the
correct answer to "when should we use the PHP\ prefix?" is "never", I urge
you to put forward an RFC making that the policy.




> Rather than having more rules (quite a few of which I don't agree
> with), time and effort would be better spent on reviewing code and
> using features before releases e.g. to avoid situations like the FFI
> api being difficult to use.
>


This is pure whataboutery; the idea that reading a few naming conventions
will be such a burden that somebody would have no time to review a feature
is frankly ridiculous. Nor will the lack of a naming convention mean that
no time needs to be spent naming things - quite the contrary, it will mean
more time is wasted debating every case.

It's worth stressing that naming conventions are not new - we've had them
for global functions for many many years. We may talk about "putting things
into namespaces", but PHP's namespaces really are just names, so this RFC
could easily be called "update naming conventions for classes".

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Gabriel Caruso]

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

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

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.0alpha3 should be expected in 2 weeks, i.e. on 23 Jul 2020.

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

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso

PHP 8.0.0 Alpha2 Manifest:

```
php-8.0.0alpha2.tar.gz
SHA256 hash:
e00e8091fe80b50c19fd815ed1d14fb4ab081137a4b47cb1e1abcfe450583647
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8EVlIWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj9/6D/9WulKof6gj0SI/+GWsp4XZMjHv
1dvYL+5x1idH76hbVxfVwMd9djGlxGSzMpHCZV6yBgddopcvFyiz7LlOhSJnPmmJ
eSNkWcqF6Qh1YtpVV6H+R4HGvL3kYQKvUYrTz0ApDk9rrCJU1x4XaG2Tbtu/dvNv
rYJHV47NPJlBSQRhqD71buynDqQb1nXbRw882D2cGz7q4yGDcWixFwXmGunW8lBg
pWWAofDpAOHHPMHc7PEUDKxnD3zj38XGNYBLEJ2eP/xWrsXM3UEg/4ERDmhi9ota
CwonVd3IgL04bB4knmT72dq/TiDNFkhV3o/riFUuUhz+md4PnCPQesb5HkkSOshv
HWrTeLf4QakoNwLXR4P8HhXaGksfG23YCLIdsj+T2jOrm6qq9Fo4W1r2vhYPhNXN
pamhgy5u63ekM8dpPeGy9WH+SK0hAT4I9j2/P42mgb0tJ2es5ZPepBF4U6wmFYx9
nA1PxymZAqORYfNQrPmJlwGoib4LGOuJugobWsVUR0BqugmV/5D0SOxgPl4VodAs
rVsoHBPc+YxJFkfJXuebBxFwJtF6Ii22wZ4JAHg6UQyy4U/lnMzdfnqAZKwj/TYO
IdbEFcr3oeMtCs4iog7RAUALAGjTABtmjHlLYfo9KUWrfWxM3qd9DOsJ5+rqqFF8
ek0FjbCnE3lLKYhomQ==
=h1QA
-END PGP SIGNATURE-

php-8.0.0alpha2.tar.bz2
SHA256 hash:
1698e0488726e978236d26c6f7e5c46f0b53a72028a4a07122045c7443a02889
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8EVlMWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjy9jEADFVPNqQJ0GZZVUKqM04drwlbdn
LqlKn7lIKFbDdrixBaqxb8/RK+JNJeK5wzbdBZOTlHlYEco+3jdjvBDgJEjDAwRR
5zlJpZlAa8P+RV34j0Hq/agC0XEYpn5VBD5k5kDyUfUGZCIVvTMhzScgSPviRNlc
c4ZXpeWBzWRubXTvMm/e8RfWwgjMAhJLDhouJNo1So/1HpvpzxaDLZbgcyfnNd/D
XEvlyozidEMkEOEO7piChIL6JiPxmICWb6Ebu60mvrjiuqRngsf6LFtP/G6G/7na
t6nto+ELlk1j28BE/YqKl/bbnvW1Glm32mD1T2JOebbxwRQxQMmQC31U6Sr1tmsb
DVE0UxYCgkcK6uBn74EQIj5+/UMBXDfGiOTX65n2pmOaCncPqb8UOkmPPb3xCLrB
xiJHVw4LhYFDGZOTr15Xfyfrvyzjd5cAf8OFnZWEMwleCIGhFclIf77kbyftKHr7
Kmmm+ZfPRHxCNTKjSZzg4fRzrLtZuxgjdWxswAYxsCYzjn3hdctFIvc5bqOnNt92
koJBPZgeISeSTxK6Wl4EpoqmVOOls5Q04RZwc8xduB5WptWR5J6RdM19KrSXf1/1
nyTHudONttFsUPQ5B7L/HYqLituGA3e3p5c/FI8NyKRcenBI1jzQRW+n2Gqinkd9
uI40ucDZBPxsv7ZN7w==
=nJBD
-END PGP SIGNATURE-

php-8.0.0alpha2.tar.xz
SHA256 hash:
9071e16db76a91df4b8d485eff0d7a40f57053c97709ceb59912c99ac4b95d89
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl8EVlMWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj8GMD/45uo4yTh2+9aN1u9N+xzc4BKKB
HhtKkCfne5GhIDjWY57m7PnBfhbQCQpuFjpoNajA893oxKWmKSlycBfBai6c+7fd
+BefYFKs1EtOv0VPYWxufAXClBRTZJh515LCz3UNMFnZg0SsWEhbLJzTvPcUXirE
N86LQ5bebibCDQCX+TBF10xDiVDxlUJ7s8jWRah4pZg9HCHEw9mYCxzsvUx6QB/V
DNQHwKK4sSUBawrJf5OIQUz4hihyr5RuMH0B0pz2qv8ps9pZwzj/NQ+fppNxSfYz
ZLEs5v6CsSl26QP/IB8l7PEoA7Pq2UZVRm7TbE3Qfc4KNb4fn0bxRNfuZVLlLULf
ROF3ya7gUwfz/F6GLkxfs5E1ILOrvOT9Xh6QzMT6Uo9d+dtE2jOGfYT1lg8qEEBW
0BhJQjTSoNUcDIyQnPtguQALcSjcoAp3UGZ5Y+HeJ9X9SbaheBUnVGt064TwjRsl
JxHn3iHpLM5dQDXpcRtn9Vc3ufe8wguK45/JLTHrJifSRPu4bvtuhIKWo42fEg7x
eN1g8djIma2r0rj0v0QBm4zw9tvvtZrV+wcJXj/SDq7mYkJ5bWRigFXcgA9Zf3KL
TgHzU9NC3qhKmYSki1Kb+mML+exvy1/YJlHURorMwArhBuNM7S5XoOB1Wml42LAO
h/0TXT/mQ33Bxc4mPQ==
=sLi9
-END PGP SIGNATURE-
```

Re[2]: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems

[Кирилл Несмеянов]

> One other thing that probably also should be addressed is the
> behaviour around closures that was noted in the RFC
>  https://wiki.php.net/rfc/ffi#php_callbacks :
 
During work with FFI, I did not encounter problems associated with this. There 
are more significant ones, for example, the lack of a cast of types in 
structures:

$struct = FFI::cdef(‘struct Test { char* string_field; }’)->new(‘Test’);
$struct->string_field = «string»; // Error
 
However, these internal problems including a memory leak when working with 
anonymous functions, I found it unnecessary in this RFC. Maybe a little later.
 
> So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
> name that is somewhat meaningful.
 
I'm afraid in this case, developers will use an easier to use feature. And this 
means that just so we can’t deprecate it later.
 
However, if this argument is not very convincing, then as the name of the new 
function, I would suggest «FFI::fromSource(...)».
  
>Четверг, 9 июля 2020, 11:01 +03:00 от Dan Ackroyd :
> 
>On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов < n...@xakep.ru > wrote:
>>
>> I would like to start discussion about the «FFI Improvements» RFC. At the 
>> moment, I do not have the right to create wiki page, so I post it on the 
>> github:  
>> https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md
>>
>
>Thanks for starting this discussion. I think FFI definitely needs to
>be improved before it will see widespread adoption.
>
>> Please note that for backward compatibility, allow option with
>> passing a string as the second argument to the FFI::cdef() method.
>
>Rather than changing the function signature of FFI::cdef, I think it
>would be better to introduce a new function, and then at some point
>deprecate and remove the old one (if anyone cares to).
>
>So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
>name that is somewhat meaningful.
>
>For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible.
>It would be really good if someone involved in getting FFI into core
>could comment if there was any specific reason for not doing that
>already.
>
>One other thing that probably also should be addressed is the
>behaviour around closures that was noted in the RFC
>https://wiki.php.net/rfc/ffi#php_callbacks :
>
>> It's possible to assign PHP closure to native variable of
>> function pointer type (or pass it as a function argument).
>> This works, but this functionality is not supported on all libffi
>> platforms, it is not efficient and leaks resources by the end of
>> request. It's recommended to minimize the usage of PHP callbacks.
>
>I really don't know what can or should be done for that, but having a
>feature that can't be used safely seems like a bad feature.
>
>cheers
>Dan
>Ack
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit:  https://www.php.net/unsub.php
>  
 
 
--
Kirill Nesmeyanov
 

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Dan Ackroyd]

On Tue, 7 Jul 2020 at 15:47, Larry Garfield  wrote:
>
> This has reached the 2 week mark, but there's not been much discussion.

Unless I'm having a massive reading failure, this RFC has been
announced twice. And feedback was provided before:

https://externals.io/message/109646#109647
https://externals.io/message/109646#109648

>From the RFC:
> Every new global class, however, creates a potential namespace collision
> with existing user-space code and thus a potential for backward
> compatibility breaks.

This doesn't appear to be an actual problem for the PHP ecosystem.

The vast majority of code in libraries is in namespaces, which avoids
there being a problem that needs addressing.

> Anyone else want to weigh in?

I still don't think this RFC is a good way to improve the general
situation of PHP.

Rather than having more rules (quite a few of which I don't agree
with), time and effort would be better spent on reviewing code and
using features before releases e.g. to avoid situations like the FFI
api being difficult to use.

cheers
Dan
Ack

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

Re: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems

[Dan Ackroyd]

On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов  wrote:
>
> I would like to start discussion about the «FFI Improvements» RFC. At the 
> moment, I do not have the right to create wiki page, so I post it on the 
> github:  
> https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md
>

Thanks for starting this discussion. I think FFI definitely needs to
be improved before it will see widespread adoption.

> Please note that for backward compatibility, allow option with
> passing a string as the second argument to the FFI::cdef() method.

Rather than changing the function signature of FFI::cdef, I think it
would be better to introduce a new function, and then at some point
deprecate and remove the old one (if anyone cares to).

So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
name that is somewhat meaningful.

For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible.
It would be really good if someone involved in getting FFI into core
could comment if there was any specific reason for not doing that
already.

One other thing that probably also should be addressed is the
behaviour around closures that was noted in the RFC
https://wiki.php.net/rfc/ffi#php_callbacks:

> It's possible to assign PHP closure to native variable of
> function pointer type (or pass it as a function argument).
> This works, but this functionality is not supported on all libffi
> platforms, it is not efficient and leaks resources by the end of
> request. It's recommended to minimize the usage of PHP callbacks.

I really don't know what can or should be done for that, but having a
feature that can't be used safely seems like a bad feature.

cheers
Dan
Ack

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

Re: [PHP-DEV] [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects

[Michał Marcin Brzuchalski]

Hi Mike

śr., 8 lip 2020 o 22:20 Mike Schinkel  napisał(a):

> Yes, excited to see this.
>

That’s good to hear.


> Would adding a method that allows getting a specific stack frame rather
> than the entire trace if you know which on you want take up less memory
> and/or perform better?
>
> Something like StackFrame::getFrame(1) which would be functionally
> equivalent to StackFrame::getTrace()[1]?
>

Indeed, this makes sense.
Since I already consider adding an `$offset` parameter to `getTrace()`,
adding a dedicated static method will be trivial.

Cheers,
--
Michał Marcin Brzuchalski

Re: [PHP-DEV] [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects

[Michał Marcin Brzuchalski]

Hi Levi,

śr., 8 lip 2020 o 22:25 Levi Morrison 
napisał(a):

> Any opposition for a parameter to limit stack depth? It's something
> I'd like on the old API too.
>

I've updated the RFC with the same arguments as in `debug_backtrace()`
function.
I'm also considering adding a third option for `int $offset = 0` in some
known cases
we want by default skip more frames at the beginning when they're known
this would
reduce copying values from skipped frames.

I've also added two additional properties and related methods:

1) property `?string $object_class = null` and method `public function
getObjectClass(): ?string`

They expose an object class name which is useful in case we don't wanna
populate frames with the objects.

The additional information could fulfil the
https://bugs.php.net/bug.php?id=45351  if frames as objects
would be got accepted as a replacement in `Exception::getTrace()`.

2) property `?\Closure $closure = null` and method `public function
getClosure(): ?\Closure`

They expose a closure which is useful in case the frame was produced by
closure call.
This was added to keep the `function` property compatibility with frames
produced by `debug_backtrace()`.

The additional information could fulfil the
https://bugs.php.net/bug.php?id=62325 if frames as objects
would be got accepted as a replacement in `Exception::getTrace()`.

Cheers,
--
Michał Marcin Brzuchalski