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

Hey all Am 08.07.24 um 07:05 schrieb Juliette Reinders Folmer: On 8-7-2024 6:57, Andreas Heigl wrote: Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The  suggested `hash()` replacements for the md5/s

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

On 8-7-2024 6:57, Andreas Heigl wrote: Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The suggested `hash()` replacements for the md5/sha1* functions have the exact same functionality, which the RFC

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

Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...] I also don't agree that there are "more appropriate replacements available". The  suggested `hash()` replacements for the md5/sha1* functions have the exact same functionality, which the RFC considers "incorrect use", so what are w

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

Hi Juliette, > I honestly don't understand what you are saying here. > > If 0.285 is a string, then no type conversion would be needed to pass it to > BCMath anyhow. > Otherwise, 0.285 would be a floating point number already. > > If the type for BCMath would become `int|string`, in non-strict

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

On 8-7-2024 5:18, Saki Takamachi wrote: Hi Juliette, Hi Saki, Just wondering: why `int|string` instead of `float|string` ? In my experience, floats are the more pertinent type for which to use the BCMath extension. Smile, Juliette Since floating point numbers always contain a certain amount

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

Hi Juliette, > Hi Saki, > > Just wondering: why `int|string` instead of `float|string` ? > In my experience, floats are the more pertinent type for which to use the > BCMath extension. > > Smile, > Juliette Since floating point numbers always contain a certain amount of error, I believe that

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

On 2-7-2024 20:05, Gina P. Banyard wrote: On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer wrote: On 25-6-2024 16:36, Gina P. Banyard wrote: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc/deprecat

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Wed, Jul 3, 2024 at 5:18 PM Michael Morris wrote: > Hello all. Hitting reset again as the primary problem at hand has become > clear. Let's recap it. > > Autoloading is great for loading packages, but it can't load different > versions of the same package at the same time. Why would you want

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

On 8-7-2024 3:23, Saki Takamachi wrote: Hi all, I created an RFC and put it in discussion status. https://wiki.php.net/rfc/allow_int_args_to_bcmath_function It's a very simple RFC, so unless there's any major discussion, I plan to start voting on this on 7/23, after two weeks have passed. Reg

[PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

Hi all, I created an RFC and put it in discussion status. https://wiki.php.net/rfc/allow_int_args_to_bcmath_function It's a very simple RFC, so unless there's any major discussion, I plan to start voting on this on 7/23, after two weeks have passed. Regards, Saki

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

> On Jul 6, 2024, at 8:01 PM, Michael Morris wrote: > > Some context from where I'm coming from. I have been working exclusively in > React, NodeJS and Go up till about a year ago, and in Drupal before that - it > being 10 years since the last time I looked at WordPress. I need work though, >

Re: [PHP-DEV] [RFC] Static class

> On Jul 7, 2024, at 4:08 PM, Bilge wrote: > > On 24/06/2024 00:10, Bilge wrote: >> Hi Internals! > I am excited to announce the final implementation for Static Class is ready > for review at and includes a > brief summary of the key semantics of the

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

On Friday, 5 July 2024 at 18:11, Claude Pache wrote: > * For each deprecation, it would be nice to provide explicitly the text of > the deprecation notice so that we can guarantee that it will be helpful for > users, see https://github.com/php/php-src/issues/14320 Considering that until recent

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

On Sunday, 7 July 2024 at 22:01, Nicolas Grekas wrote: > I don't see any mention of Stringable objects in the RFC. Can you please > describe how they behave when used as string indexes, and if you're proposing > any changes for them Hello Nicolas, All objects behave the same for string offse

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

Hi Gina, Impressive RFC! Le jeu. 4 juil. 2024 à 15:55, 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 ti

[PHP-DEV] Re: [RFC] Static class

On 24/06/2024 00:10, Bilge wrote: Hi Internals! I am excited to announce the final implementation for Static Class is ready for review at and includes a brief summary of the key semantics of the feature. Furthermore, the 1.3 (presumed) final version

Re: [PHP-DEV] [RFC] Static class

On 30/06/2024 16:10, Tim Düsterhus wrote: I strongly favor an opinionated RFC where the RFC author did their research and makes it clear why the proposal is the right choice and backs this up by proper arguments. Of course this doesn't mean that the RFC author should not listen to the list disc

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

On Thu, Jul 4, 2024, at 8:52 AM, 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] Operator Overrides -- Lite Edition

After some consideration and lack of enthusiasm; I'm withdrawing this RFC. — Rob

Re: [PHP-DEV] [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

Hi all, > Hi internals, > > Created a follow-up RFC for the BCMath\Number class. This RFC also contains > proposed changes to GMP's bool cast. I have proposed similar changes to > BCMath, so for procedural efficiency I have combined them into the same RFC. > > Note that although they are comb

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Sun, Jul 7, 2024, at 12:55, ignace nyamagana butera wrote: > Hi Máté, > > > Supporting IANA registered schemes is a valid request, and is > definitely useful. However, I think this feature is not strictly > required to have in the current RFC. > > True. Having a WHATWG compliant parser in

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Sun, Jul 7, 2024, at 12:40, Rob Landers wrote: > On Sun, Jul 7, 2024, at 11:13, Máté Kocsis wrote: >> Hi Ignace, >> >>> As far as I understand it, if this RFC were to pass as is it will model >>> PHP URLs to the WHATWG specification. While this specification is >>> getting a lot of traction l

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Máté, > Supporting IANA registered schemes is a valid request, and is definitely useful. However, I think this feature is not strictly required to have in the current RFC. True. Having a WHATWG compliant parser in PHP source code is a big +1 from me I have nothing against that inclusion.

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Sun, Jul 7, 2024, at 11:13, Máté Kocsis wrote: > Hi Ignace, > >> As far as I understand it, if this RFC were to pass as is it will model >> PHP URLs to the WHATWG specification. While this specification is >> getting a lot of traction lately I believe it will restrict URL usage in >> PHP instea

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

Q On Sun, Jul 7, 2024, 03:03 Michael Morris wrote: > > > >> >> ... >> Many (most?) people on PHP Internals view WordPress coding standards as >> bad and some even view addressing WordPress developers needs as bad for >> PHP >> > > I really don't want to get into that crossfire. WordPress i

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Stephen, I agree with the others, the static parser class is weird. Either put the > static methods on the url class, or make the parser an instance with > options. > Yes, I was sure that many people would find the signature of the parser weird, and I can totally understand it. Since I don't h

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, As far as I understand it, if this RFC were to pass as is it will model > PHP URLs to the WHATWG specification. While this specification is > getting a lot of traction lately I believe it will restrict URL usage in > PHP instead of making developer life easier. While PHP started as a >

Re: [PHP-DEV] [RFC]I'd like to see the RFCs that deprecate the FFI non-static approach start voting

1. I only discovered this change when I pulled the master code when adding FFI::addrValue(). Also, I have submitted this improvement proposal PR on May 20, 2022, because I didn't push it forward because of my own network issues. 2. The reason why it is rude is because the implementation of the PR s