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

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

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

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!

[PHP-DEV] Microsoft Support of PHP on Windows

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

[PHP-DEV] PHP 7.3.20 Released

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

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

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

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

> 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-DEV] PHP 7.4.8 Released!

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

[PHP-DEV] PHP 7.2.32 Released

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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