Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 27 July 2024 23:14:32 BST, Morgan wrote: >Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions for >both, and then when SHA4 comes along (as it inevitably will) another >standalone function for one of its variants? You tell me. As I have repeatedly said, I don't actua

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 27, 2024, at 7:24 AM, Christoph M. Becker wrote: > > Hmm, such soft deprecations should be a good thing, but I'm afraid they > are not really reaching much of the user base. Remember ext/mysql? > That was soft deprecated for "centuries", but still support channels > were burning when it

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 27, 2024, at 8:36 AM, Rowan Tommins [IMSoP] > wrote: > On 27 July 2024 00:58:17 BST, Morgan wrote: >> >> I'm not talking about the MD5 or SHA1 algorithms or whether they should or >> shouldn't be used. I'm just talking about the functions themselves. md5(), >> md5_file(), sha1(), and

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

On Sun, 2024-07-28 at 00:48 +0200, Claude Pache wrote: > > For the case of functions (and constants) in the global namespace, > there was an RFC on the subject about 4 years ago, which has been > declined; see: https://wiki.php.net/rfc/use_global_elements and the > discussion threads referenced

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

> Le 25 juil. 2024 à 05:22, Nick Lockheart a écrit : > > 1. Could we have a global setting (maybe php.ini) that makes all built- > in functions (not built in classes) directly accessible in any > namespace? That is: > > // php.ini > AlwaysUseGlobalFunctions = yes > > Then: > // myclass.php >

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

On 27/07/2024 23:30, Nick Lockheart wrote: What are people's thoughts on requiring a use statement to make built- in classes available in the global namespace? No.

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

> > I think a better solution would be to have one namespace for all > > bundled classes, so that a specific namespace is reserved in > > advance. > > Needing to prefix everything by \PHP or something like this would > provide for a terrible developer experience when using the standard > library.

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Sun, Jul 28, 2024, at 00:14, Morgan wrote: > On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote: > > > > > > On 27 July 2024 00:58:17 BST, Morgan wrote: > >> > >> I'm not talking about the MD5 or SHA1 algorithms or whether they should or > >> shouldn't be used. I'm just talking about the funct

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote: On 27 July 2024 00:58:17 BST, Morgan wrote: I'm not talking about the MD5 or SHA1 algorithms or whether they should or shouldn't be used. I'm just talking about the functions themselves. md5(), md5_file(), sha1(), and sha1_file(). They only

Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers

On Thu, Jul 4, 2024, at 15:52, Gina P. Banyard wrote: > Hello internals, > > I would like to formally open the discussion on an RFC I've been working on > for the past year: > https://wiki.php.net/rfc/container-offset-behaviour > > As DokuWiki is a bit of a faff at times, the Markdown sources ar

Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers

> Le 4 juil. 2024 à 15:52, Gina P. Banyard a écrit : > > Hello internals, > > I would like to formally open the discussion on an RFC I've been working on > for the past year: > https://wiki.php.net/rfc/container-offset-behaviour > > As DokuWiki is a bit of a faff at times, the Markdown sourc

Re: [PHP-DEV] [RFC] Working With Substrings

On Sat, Jul 27, 2024, at 15:26, Christoph M. Becker wrote: > On 15.02.2023 at 06:18, Rowan Tommins wrote: > > > On 15 February 2023 02:35:42 GMT, Thomas Hruska > > wrote: > > > >> On 2/14/2023 2:02 PM, Rowan Tommins wrote: > >> > >> I thought about that but didn't know how well it would be recei

Re: [PHP-DEV] [RFC] Working With Substrings

On 15.02.2023 at 06:18, Rowan Tommins wrote: > On 15 February 2023 02:35:42 GMT, Thomas Hruska > wrote: > >> On 2/14/2023 2:02 PM, Rowan Tommins wrote: >> >> I thought about that but didn't know how well it would be received nor, >> perhaps more importantly, the direction it should take (i.e. a

Re: [PHP-DEV] Imagick maintainers

On 13.06.2024 at 12:26, Vorisek, Michael wrote: > is here anyone who has access to https://github.com/Imagick/imagick repo or > direct contact to the maintainer? > > We use Imagick in our projects and I would be happy if the latest master can > be released for PHP 8.3 and master adjusted for PHP

Re: [PHP-DEV] Explicit callee defaults

On 27/07/2024 13:52, Rob Landers wrote: On Sat, Jul 27, 2024, at 11:50, Bilge wrote: On 27/07/2024 10:41, Rob Landers wrote: This seems like a case for code generation I don't understand how this has anything to do with code generation. I understand what composer-attribute-collector is doing,

Re: [PHP-DEV] Explicit callee defaults

On Sat, Jul 27, 2024, at 11:50, Bilge wrote: > On 27/07/2024 10:41, Rob Landers wrote: >> >> This seems like a case for code generation > I don't understand how this has anything to do with code generation. I > understand what composer-attribute-collector is doing, and see no application > for i

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 27 July 2024 00:58:17 BST, Morgan wrote: > >I'm not talking about the MD5 or SHA1 algorithms or whether they should or >shouldn't be used. I'm just talking about the functions themselves. md5(), >md5_file(), sha1(), and sha1_file(). They only exist because there wasn't the >generic hash a

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26.07.2024 at 19:33, Rowan Tommins [IMSoP] wrote: > On Fri, 26 Jul 2024, at 15:20, Larry Garfield wrote: > >> One thing to remind people about, the deprecations for md5(), sha1(), >> and uniqid() explicitly say they cannot be outright removed before PHP >> 10. That's at least 6 years away. Th

Re: [PHP-DEV] [RFC] [VOTE] Make the GMP class final

On Saturday, 13 July 2024 at 16:05, Gina P. Banyard wrote: > Hello Internals, > > I have just opened the vote for the "Make the GMP class final" RFC: > https://wiki.php.net/rfc/gmp-final > > The vote will last for 2 weeks from today July 13th 2024 to July 24th 2024. > > Best regards, > > Gina

[PHP-DEV] Re: [PHP-DEV] Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4 — Use a carrot, not a stick.

On Fri, Jul 26, 2024 at 6:14 PM Mike Schinkel wrote: > Frankly, if the pro-deprecation voters in the PHP community are not > willing to pursue an initiative that proactively seeks to help users > remediate and educate users about security concerns then I would argue > *they* do not really care ab

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 26, 2024, 04:58 Tim Düsterhus wrote: > > I just Googled "PHP tutorial" and found https://www.phptutorial.net/ as > the second search result, which considers itself to be "the modern PHP > tutorial". > > I've clicked at the CSRF section > (https://www.phptutorial.net/php-tutorial/php-c

Re: [PHP-DEV] Explicit callee defaults

On 27/07/2024 10:41, Rob Landers wrote: This seems like a case for code generation I don't understand how this has anything to do with code generation. I understand what composer-attribute-collector is doing, and see no application for it (or something like it) here. Could you explain a bit f

Re: [PHP-DEV] Explicit callee defaults

On Fri, Jul 26, 2024, at 23:54, Bilge wrote: > Hi Internals, > > New RFC idea just dropped. When writing a function, we can specify defaults > for its parameters, and when calling a function we can leverage those > defaults *implicitly* by not specifying those arguments or by "jumping over" >

Re: [PHP-DEV] Explicit callee defaults

On 27.07.2024 at 09:00, Bilge wrote: > On 26/07/2024 23:42, Christoph M. Becker wrote: > >> I have only skimmed your suggestion, but it sounds quite similar to >> . > > Yes, it appears to be exactly that. > > I suppose that means there is no hope of pursuing th

Re: [PHP-DEV] Explicit callee defaults

> On Jul 27, 2024, at 3:19 AM, Rob Landers wrote: > There’s nothing stopping you from doing that, except your autoloader. If you > wanted to have every class ending with Arg load the same class without arg; > so QueryArg and Query are usually in the same file (but can be in separate > files too

Re: [PHP-DEV] Explicit callee defaults

On Sat, Jul 27, 2024, at 02:04, Mike Schinkel wrote: > > On Jul 26, 2024, at 6:42 PM, Christoph M. Becker wrote: > > > > I have only skimmed your suggestion, but it sounds quite similar to > > . > > I would really love to hear from some of those who voted "

Re: [PHP-DEV] Explicit callee defaults

On 26/07/2024 23:42, Christoph M. Becker wrote: I have only skimmed your suggestion, but it sounds quite similar to . Cheers, Christoph Hi Christoph, Yes, it appears to be exactly that. I suppose that means there is no hope of pursuing this, since the vot