Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function
Thank you for your input Levi, this perspective wasn't mention before. I agree with deprecation, that's why I removed this part from the RFC. I left separate vote on creating aliases for the extension though, as from the discussion this was not so certain and clear to everyone. Kind regards, Adam
Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function
On Wed, 15 Nov 2023 at 23:43, Levi Morrison wrote: > On Wed, Nov 15, 2023 at 2:26 PM Jorg Sowa wrote: > > > > Hello internals! > > I have just opened voting on the RFC to add 4 new rounding modes to > round() > > function. > > > > Voting will end November 30th, 00:00 GMT. > > > > Link: > > https://wiki.php.net/rfc/new_rounding_modes_to_round_function > > > > I'm sorry for previous message, but completely missed the title of the > > message. > > > > Kind regards, > > Jorg > > I didn't pay attention to the discussion. Sorry. > > I object to changing the intl code to add aliases. The intl extension > is a wrapper around ICU, and I don't think it's a wise choice to > modify it because you think "ROUND_TOWARD_ZERO" is better than > "ROUND_DOWN". I agree the name is better, but that's not really how > extension maintenance should work. I definitely don't think we should > then _deprecate_ the ROUND_DOWN/ROUND_UP constants in ICU, given that > the extension itself hasn't deprecated them and is still maintained. I > am surprised nobody pointed this out before. > > I don't have any objection to the rounding modes themselves. > Personally I am fine with adding aliases to ext/intl, it is not because the extension is a wrapper that we can't enhance it to be somewhat consistent. However, I do agree that deprecating the existing constants is a bad idea. But the RFC vote, as far as I can understand, is not about deprecating it in this release. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function
On Wed, Nov 15, 2023 at 2:26 PM Jorg Sowa wrote: > > Hello internals! > I have just opened voting on the RFC to add 4 new rounding modes to round() > function. > > Voting will end November 30th, 00:00 GMT. > > Link: > https://wiki.php.net/rfc/new_rounding_modes_to_round_function > > I'm sorry for previous message, but completely missed the title of the > message. > > Kind regards, > Jorg I didn't pay attention to the discussion. Sorry. I object to changing the intl code to add aliases. The intl extension is a wrapper around ICU, and I don't think it's a wise choice to modify it because you think "ROUND_TOWARD_ZERO" is better than "ROUND_DOWN". I agree the name is better, but that's not really how extension maintenance should work. I definitely don't think we should then _deprecate_ the ROUND_DOWN/ROUND_UP constants in ICU, given that the extension itself hasn't deprecated them and is still maintained. I am surprised nobody pointed this out before. I don't have any objection to the rounding modes themselves. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes
Hi Daniil and thanks for the RFC. I would like to submit an RFC and PR to add support for final anonymous > classes, /or/ make all anonymous classes final by default, with or > without the possibility to make them non-final. > > Here's the URL of the RFC: > https://wiki.php.net/rfc/final_anonymous_classes > > I'd more more than glad to receive some feedback! > I've read the RFC proposing to make anonymous classes final by default, and as defender of backward compatibility, I have concerns. The RFC cites potential performance gains and a cleaner codebase as justifications. However, the performance improvement seems limited to a narrow use case – anonymous classes aren't that common in everyday PHP coding. Without concrete data demonstrating significant performance benefits, this argument doesn't seem strong enough to warrant a BC break. Regarding the argument for cleaner code, while I acknowledge the appeal of streamlined design, we must remember that breaking backward compatibility isn't the right tool for correcting past decisions. PHP has a rich history of handling such transitions gracefully, typically introducing changes with a deprecation notice in a minor version before a major shift. This approach has served our community well, maintaining stability and predictability. Is this change truly worth such a departure from our norms? I believe not. Making anonymous classes final by default goes against the principle of least surprise, a core philosophy in PHP where regular classes aren't final by default. While I'm open to Proposal 1, which introduces final anonymous classes without breaking BC, Proposals 2 and 3 are a different story. They seem to suggest we can break backward compatibility on a whim, but our release process (https://wiki.php.net/rfc/releaseprocess) clearly advises against such moves in minor releases. Overriding this policy should require a more substantial rationale. As an example, in my work with Symfony, I've utilized class_alias to extend anonymous classes within a test suite ( https://github.com/symfony/symfony/blob/c9e7809f045a1366afe2c2643bae15751ae7b500/src/Symfony/Component/VarExporter/Tests/LazyProxyTraitTest.php#L294). While the RFC suggests alternative methods to achieve something similar, the essence of preserving backward compatibility is about ensuring stability and reliability without imposing the burden of code modification on userland. In summary, I advocate for the RFC to focus on the non-BC-breaking option. Let's maintain our commitment to stability and gradual evolution in PHP. Cheers, Nicolas
[PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function
Hello internals! I have just opened voting on the RFC to add 4 new rounding modes to round() function. Voting will end November 30th, 00:00 GMT. Link: https://wiki.php.net/rfc/new_rounding_modes_to_round_function I'm sorry for previous message, but completely missed the title of the message. Kind regards, Jorg
Re: [PHP-DEV] Re: Change default method of disabling JIT for PHP 8.4
On Wed, Nov 15, 2023, at 5:07 PM, Daniil Gentili wrote: > Hi all, I've created the actual RFC: > https://wiki.php.net/rfc/jit_config_defaults > > Regards, > > Daniil Gentili. Seems like an obvious usability win to me. +1 --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [VOTE] Adding bcround, bcfloor and bcceil to BCMath
Hi internals, I started voting on my RFC "Adding bcround, bcfloor and bcceil to BCMath”. Voting will end November 30th, 00:00 GMT. https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Final anonymous classes
Hi, Regarding the RFC itself, I find the voting options unclear. It says that they are mutually exclusive, but it doesn't say what happens when multiple are accepted. Personally I can see myself voting for both "Option 1" and "Option 2", because I believe it is useful if users would be able to make them final for consistency, but I would find it even more useful if they would all be final by default, but would not find it useful to introduce a new 'open' keyword. Some other folks might want to see all anon classes final by default, but don't care about whether there is the escape hatch or not and thus would vote for all 3 options. Thanks for all the tips, did everything (I did indeed forget to add the rfc to the main page, thanks for reminding me!). Regarding the voting options, all three options are mutually exclusive, but since some people (myself included) may be OK with more than one of the following options and may vote in favor of more than one option, I would propose a tie-breaker second vote in case more than one of the options finish with the same number of favorable votes. In this second, eventual tie-breaker vote, voting favorably for only one of the options would be allowed. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [Discussion] Final anonymous classes
Hi all, I would like to submit an RFC and PR to add support for final anonymous classes, /or/ make all anonymous classes final by default, with or without the possibility to make them non-final. Here's the URL of the RFC: https://wiki.php.net/rfc/final_anonymous_classes I'd more more than glad to receive some feedback! Regards, Daniil Gentili.
[PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default
Hi all, I would like to submit an RFC and PR to change a few INI defaults for opcache, changing how JIT is disabled by default. Here's the URL of the RFC: https://wiki.php.net/rfc/jit_config_defaults. I'd more more than glad to receive some feedback! Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Final anonymous classes
Hi On 11/15/23 20:03, Tim Düsterhus wrote: On 11/15/23 18:41, Daniil Gentili wrote: I've created the RFC, I'd be more than glad to receive feedback: https://wiki.php.net/rfc/final_anonymous_classes The official start of the discussion period should likely be announced in a separate thread that also contains the "RFC" keyword within the Subject, otherwise it might be missed. And one more note, it appears that neither of your two RFCs are listed on the overview page at: https://wiki.php.net/rfc Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Final anonymous classes
Hi On 11/15/23 18:41, Daniil Gentili wrote: I've created the RFC, I'd be more than glad to receive feedback: https://wiki.php.net/rfc/final_anonymous_classes The official start of the discussion period should likely be announced in a separate thread that also contains the "RFC" keyword within the Subject, otherwise it might be missed. Regarding the RFC itself, I find the voting options unclear. It says that they are mutually exclusive, but it doesn't say what happens when multiple are accepted. Personally I can see myself voting for both "Option 1" and "Option 2", because I believe it is useful if users would be able to make them final for consistency, but I would find it even more useful if they would all be final by default, but would not find it useful to introduce a new 'open' keyword. Some other folks might want to see all anon classes final by default, but don't care about whether there is the escape hatch or not and thus would vote for all 3 options. (I'm happy to repeat that above paragraph in the new thread, once you create it, but this gives you some time to think about it already) Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Final anonymous classes
Hi all, I've created the RFC, I'd be more than glad to receive feedback: https://wiki.php.net/rfc/final_anonymous_classes Thanks, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] [RFC]
Hello internals! I have just opened voting on the RFC to add 4 new rounding modes to round() function. Voting will end November 30th, 00:00 GMT. Link: https://wiki.php.net/rfc/new_rounding_modes_to_round_function Kind regards, Jorg
[PHP-DEV] Re: Change default method of disabling JIT for PHP 8.4
Hi all, I've created the actual RFC: https://wiki.php.net/rfc/jit_config_defaults Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Debian Upgrade
Hi! In the last few days, I have upgrade all our Digital Ocean droplets from Debian 10 (or 9!) to 12. That also means they now run PHP 8.2. I have not encountered any problems, but if you do, please let me know! cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP-8.1 closed for bug fixes, security fixes only
Le 10/11/2023 à 20:57, Ben Ramsey a écrit : Hi, all! According to the supported versions page[^1] (and our release process documentation), active support for PHP-8.1 ends on 25 Nov 2023. Since our release cycle has a release falling on 23 Nov, this means PHP 8.1.26 is the last bug-fix release for the 8.1 series. Following PHP 8.1.26, PHP 8.1 will be in security maintenance mode. I know there was some confusion around this, and I apologize that we didn’t make this clear earlier (though the dates have been posted for a while ;-) ). PHP 8.1.26RC1 was technically the last chance to get in bug fixes and have them tested prior to the release on 23 Nov. Unfortunately, we’ve had a few bug fixes merged into the PHP-8.1 branch since yesterday, and I’ll work with Patrick and others on figuring out what to do with these. Sorry to have push such fix (zip ext) Feel free to revert (IMHO this is really a minor issue for very specific usage) IIRC on previous versions, the branch was close on date (25th) which means we have 1 more bugfix version for such late fixes Remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
