Re: [PHP-DEV] [Early Feedback] Pattern matching

On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote: > On Mon, Jun 24, 2024 at 9:54 PM Robert Landers > wrote: > > > > > The first means b is an optional key, but if it’s there, can only be a > > > string. The second says b is a required key, but it may be a string or > > > null. If there were

Re: [PHP-DEV] [Early Feedback] Pattern matching

On 25 June 2024 00:31:56 BST, Larry Garfield wrote: > >* There's not been much discussion of range patterns. Anyone want to weigh in >on those? I didn't even notice them until someone else mentioned some detail of the syntax. Like regex patterns and the generic-like array syntax, they loo

Re: [PHP-DEV] [RFC] [discussion] Deprecate FFI instance calls to non-static methods instead of static methods

On Sat, Jun 22, 2024 at 6:21 AM chopins xiao wrote: > I've added a new RFC to deprecate FFI instance calls to non-static method. > > The PR > *https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8 >

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Tue, Jun 25, 2024 at 2:48 AM Larry Garfield wrote: > > On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote: > > > To that end, we're looking for *very high level* feedback on this RFC: > > > > https://wiki.php.net/rfc/pattern-matching > > Hi folks. Thank you to those who have offered feedba

Re: [PHP-DEV] Add $this return type

On Tue, Jun 25, 2024 at 2:29 AM radar3301 wrote: > I'm looking for initial feedback on the following proposal. > > Often, we have the following (fluent interface) setter method: > > public function setName(?string $name): static > { > $this->name = $name; > > return $this; > } > > I propo

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

Hi guys, On 25/06/2024 04:17, Stephen Reay wrote: Given a primary purpose for being able to declare a class `static` is to *signal intent*, disallowing `abstract static` classes seems at odds with that goal. What is the /intent/ of `abstract static`? How is such intent different f

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

Hi, > On 25 Jun 2024, at 15:03, Bilge wrote: > > Hi guys, > > On 25/06/2024 04:17, Stephen Reay wrote: >>> Given a primary purpose for being able to declare a class `static` is to >>> signal intent, disallowing `abstract static` classes seems at odds with >>> that goal. > What is the intent o

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Tue, Jun 25, 2024 at 9:44 AM Robert Landers wrote: > On Tue, Jun 25, 2024 at 2:48 AM Larry Garfield > wrote: > > > > On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote: > > > > > To that end, we're looking for *very high level* feedback on this RFC: > > > > > > https://wiki.php.net/rfc/pa

[PHP-DEV] Add bcdivmod() to BCMath

Hi internals, I've been working on improving performance of BCMath lately, and I found that I can get the div and mod in one calculation. This is obviously faster than calculating it twice separately. Do you think there's a demand for this feature? e.g. ``` [$quot, $rem] = bcdivmod('123', '2')

Re: [PHP-DEV] Add $this return type

On Tue, Jun 25, 2024 at 3:28 AM radar3301 wrote: > I'm looking for initial feedback on the following proposal. > > I propose to add "$this" as a return type, ie: > > Worth reading: - the previous RFC that didn't got to a voting stage: https://wiki.php.net/rfc/this_return_type - the discussion thr

Re: [PHP-DEV] Add bcdivmod() to BCMath

On 2024-06-25 21:11, Saki Takamachi wrote: Hi internals, I've been working on improving performance of BCMath lately, and I found that I can get the div and mod in one calculation. This is obviously faster than calculating it twice separately. Do you think there's a demand for this feature?

Re: [PHP-DEV] Add bcdivmod() to BCMath

On Tue, Jun 25, 2024, at 9:11 AM, Saki Takamachi wrote: > Hi internals, > > I've been working on improving performance of BCMath lately, and I > found that I can get the div and mod in one calculation. This is > obviously faster than calculating it twice separately. > > Do you think there's a dem

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

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/deprecations_php_8_4 As a reminder, this list has been compiled over the course of the past year by various different people. And as usual, each deprecation will

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

On Sun, 23 Jun 2024, Larry Garfield wrote: > On Sun, Jun 23, 2024, at 6:10 PM, Bilge wrote: > > Hi Internals! > > > > I am pleased to present my first RFC: Static class > > . > > > > This work is based on the previous discussion thread on this list of the >

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

Hey Gina, Tim, I agree with most of these deprecations, except: * `uniqid()`, in my case (XKCD 1172) is largely used for quickly generating a semi-random string for test purposes: a suitable replacement PRNG implementation would be welcome. Even refactoring with tools like Rector will lead to qu

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Mon, 24 Jun 2024, Larry Garfield wrote: > On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote: > > * The placement of `is` on `match()` is still an open question. "The latter is more explicit, and would allow individual arms to be pattern matched or not depending on the presence of is."

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

On Tue, Jun 25, 2024, at 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/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the past

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

Please, no top posting. On Tue, 25 Jun 2024, Marco Pivetta wrote: > I agree with most of these deprecations, except: > > * `uniqid()`, in my case (XKCD 1172) is largely used for quickly > generating a semi-random string for test purposes: a suitable replacement > PRNG implementation would be we

Re: [PHP-DEV] Add bcdivmod() to BCMath

Hi, I've been working on improving performance of BCMath lately, and I found > that I can get the div and mod in one calculation. This is obviously faster > than calculating it twice separately. > > Do you think there's a demand for this feature? > > e.g. > ``` > [$quot, $rem] = bcdivmod('123', '2

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

On Tue, 25 Jun 2024 at 17:27, Marco Pivetta wrote: > * `uniqid()`, in my case (XKCD 1172) is largely used for quickly > generating a semi-random string for test purposes: a suitable replacement > PRNG implementation would be welcome. Even refactoring with tools like > Rector will lead to quite m

Re: [PHP-DEV] [RFC] Lazy Objects

On Tuesday, 4 June 2024 at 13:28, Nicolas Grekas wrote: > Dear all, > > Arnaud and I are pleased to share with you the RFC we've been shaping for > over a year to add native support for lazy objects to PHP. > > Please find all the details here: > https://wiki.php.net/rfc/lazy-objects > > We loo

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

On 25/06/2024 16:27, Marco Pivetta wrote:  * `uniqid()`, in my case (XKCD 1172) is largely used for quickly generating a semi-random string for test purposes: a suitable replacement PRNG implementation would be welcome. Even refactoring with tools like Rector will lead to quite messy code, or

Re: [PHP-DEV] Add bcdivmod() to BCMath

On Tue, 25 Jun 2024 10:11:10 +0100 Saki Takamachi wrote --- > Hi internals, > > I've been working on improving performance of BCMath lately, and I found > that I can get the div and mod in one calculation. This is obviously faster > than calculating it twice separately. > > Do

Re: [PHP-DEV] Add bcdivmod() to BCMath

Thanks all, > My only question is the pseudo-tuple return, which is rarely used in PHP > (although I've used it myself, I think exactly once), and I think this would > be the first use of it in a built in library. (I may be wrong on that.) I > don't have a particular alternative to suggest, j

Re: [PHP-DEV] [Discussion] Follow-up RFC for BCMath\Number object

Hi! This is a reminder as the feature freeze is approaching. I would like to restate my current opinion. > - Suggestions for using 64-bit integer types internally for performance This is probably unnecessary. It's already fast enough, so it might be a good idea to consider it when we need even

Re: [PHP-DEV] Add bcdivmod() to BCMath

On Tue, 25 Jun 2024 17:29:58 +0100 Saki Takamachi wrote --- > > Also, it is not practical to record the remainder in the Number object > resulting from the division. This is because there can be objects whose > division results are equal but whose remainders are different. >

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

Hi On 6/25/24 17:55, Marco Pivetta wrote: Update: Tim gave me a decent alternative that I can live with. `uniqid()` becomes `bin2hex(random_bytes(16))`. For context: Marco also pinged me on Roave Discord and I sent a quick reply from my phone. I've now added the `bin2hex(random_bytes(16))`

Re: [PHP-DEV] Add $this return type

@Alexandru: > Worth reading: Ah shoot, my search-fu failed me (it's not listed on the RFC page, and I suppose I was not using the right search terms). I'm glad to find out this rfc previously existed, and in that case, I guess I'd like to revive that discussion. :) @Luigi: > The part that I do no

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

Hi On 6/25/24 18:03, Rowan Tommins [IMSoP] wrote: Then again, if you _actually_ want it to be unique, rather than random, those aren't the right replacements anyway. They are for all intents and purposes if the generated string is long enough. By the pigeonhole principle you can't guarantee u

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

> On Jun 25, 2024, at 10:36 AM, 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/deprecations_php_8_4 >

Re: [PHP-DEV] Add bcdivmod() to BCMath

Hi Barney, > If anything I was thinking of recording the remainder in the the original > number object, not the one returned (or possibly in something like a WeakMap > keyed to it). So it does increase state and makes it technically no longer > immutable, but that change in state would not be d

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

Hi On 6/25/24 17:39, Rob Landers wrote: My only issue is md5, sha1, etc. There are many uses for them besides secure contexts. Sha1 is used by git, md5 fits snuggly in many data structures (uuidv5, for example, though some implementations also use the first 128 bits of a sha1). I believe yo

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

Hi On 6/25/24 17:49, Derick Rethans wrote: These functions are indeed often used. The documentation for uniqid has some nice big warnings too. It can be used in situations, where it is OK. Yes, the RFC acknowledges that. Replacing the algorithm underneath uniqid can (and perhaps should) be l

Re: [PHP-DEV] [Early Feedback] Pattern matching

Hi Rob On Tue, Jun 25, 2024 at 9:05 AM Rob Landers wrote: > > On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote: > > On Mon, Jun 24, 2024 at 9:54 PM Robert Landers > wrote: > > > > To be honest, this is one of the smaller concerns I have with the new > > syntax. There might be some misundersta

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Hi On 6/24/24 17:06, Nicolas Grekas wrote: Since the vote passed, we're discussing how we might use the attribute in Symfony. 2 things on the topic: 1/ We're wondering about using it at the class level despite the missing Attribute::TARGET_CLASS. ReflectionAttribute does allow reading attribute

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

> On Jun 25, 2024, at 9:17 AM, Derick Rethans wrote: > > Having read this thread, and the previous one from half a year ago, I > will do so too. In short, we shouldn't be encouraging static classes as > a bag of static functions, that ought to be just namespaced functions. Which brings us back to

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

On Mon, Jun 24, 2024 at 5:07 PM Nicolas Grekas wrote: > > > Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a > écrit : > >> >> >> On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer >> wrote: >> >>> The vote for the RFC #[\Deprecated] attribute is now open: >>> >>> https://wiki.php.net/rfc/de

Re: [PHP-DEV] Add bcdivmod() to BCMath

> > I see, I understand. > > But I don't think that's wise. For example, if we reversed the order of > the div and mod, there would be no cache and we wouldn't get the speed > boost. (Or does it cache the quotient as well?) > I don't think the cache is a good idea either, for the reasons you menti

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote: > Hi Rob > > On Tue, Jun 25, 2024 at 9:05 AM Rob Landers wrote: > > > > On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote: > > > > On Mon, Jun 24, 2024 at 9:54 PM Robert Landers > > wrote: > > > > > > To be honest, this is one of the smaller

Re: [PHP-DEV] Add bcdivmod() to BCMath

Hey Benjamin, On Tue, 25 Jun 2024 at 22:24, Benjamin Morel wrote: > > I predicted this would probably be on the agenda. Another idea is to pass >> arguments by reference, like in `exec()`. >> >> Personally, I find something like a tuple easier to use. However, without >> generics, all we know is

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

On Tuesday, 25 June 2024 at 19:06, Mike Schinkel wrote: > strtok() > = > strtok() is found 35k times in GitHub: > >> https://github.com/search?q=md5%28+language%3APHP+&type=code > > It is a commonly used as a "left part of string up to a character" in > addition to its intended use for token

Re: [PHP-DEV] [Early Feedback] Pattern matching

On 25 June 2024 21:24:32 BST, Rob Landers wrote: >The only way you’d observe this (that I can think of) is by performing a >for-each loop over the array. There are many ways you can observe the difference between an absent key and a null value; here are just a handful off the top of my head

Re: [PHP-DEV] Add $this return type

On 25-6-2024 19:53, radar3301 wrote: Sebastian Bergmann said: [snip] please not "$this" as the name for a type. Off the top of my head, I think that "same" could make sense. My primary vote would still be for "$this" as explained above, but I could potentially be persuaded to switch to "this"

Re: [PHP-DEV] Add $this return type

On Tue, 25 Jun 2024 at 23:25, Juliette Reinders Folmer < php-internals_nos...@adviesenzo.nl> wrote: > Also don't really see the need as there is the `static` return type > already. > I'd see it as useful if the type conveyed identity too, although it also means that I would never use it, since I

Re: [PHP-DEV] Add $this return type

On Tue, Jun 25, 2024 at 9:51 AM Luigi Cardamone wrote: > > Is it possible to replace "$this" with "this"? Cleaner and coherent with > "self". > That wouldn't be possible, as `this` is a valid class name: https://3v4l.org/ujGOT -- Best regards, Bruce Weirdan

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote: > > > On 25 June 2024 21:24:32 BST, Rob Landers wrote: > >The only way you’d observe this (that I can think of) is by performing a > >for-each loop over the array. > > There are many ways you can observe the difference between an ab

Re: [PHP-DEV] [RFC] Lazy Objects

On Tue, Jun 4, 2024 at 6:31 AM Nicolas Grekas wrote: > > Dear all, > > Arnaud and I are pleased to share with you the RFC we've been shaping for > over a year to add native support for lazy objects to PHP. > > Please find all the details here: > https://wiki.php.net/rfc/lazy-objects > > We look f

Re: [PHP-DEV] [Early Feedback] Pattern matching

On 2024-06-26 08:24, Rob Landers wrote: On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote: If null array values were indeed unobservable, then [] would be === to [null] (or at least ==), and a foreach over [null] would result in 0 iterations. But neither of those are the case. I think there

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

Is there a reason to keep crc32? -- Best regards, Bruce Weirdan mailto: weir...@gmail.com

Re:[PHP-DEV] [RFC] [discussion] Deprecate FFI instance calls to non-static methods instead of static methods

https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8 This PR has been merged and will probably be released in PHP 8.4, so hopefully a result will come out soon. Regards Chopin Xiao

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

> On Jun 25, 2024, at 4:51 PM, Gina P. Banyard wrote: > > > On Tuesday, 25 June 2024 at 19:06, Mike Schinkel wrote: >> >> strtok() >> = >> strtok() is found 35k times in GitHub: >> >> https://github.com/search?q=strtok%28+language%3APHP+&type=code >>

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

On Jun 25, 2024, at 22:18, Mike Schinkel wrote: > This leads me to think `strtok()` should not be deprecated given how > inefficient string handling in PHP can otherwise be, at least not without a > much more efficient object for string parsing. What would be really useful as a replacement for

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

> On Jun 24, 2024, at 11:17 PM, Stephen Reay wrote: > > > >> On 25 Jun 2024, at 09:22, Mike Schinkel wrote: >> >>> On Jun 24, 2024, at 3:53 AM, Ayesh Karunaratne >> > wrote: >>> - Why is it a class-level flag and not an attribute (similar to the >>> `#[Override]` attri

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

> On Jun 25, 2024, at 4:03 AM, Bilge wrote: > Nevertheless, the allure of early adoption is curious, and made me wonder > whether we could do both, just to support early adoption in a > backwards-compatible manner. And that is probably the best solution I've heard regarding this quandary. It

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

> On Jun 26, 2024, at 1:39 AM, Dusk wrote: > > On Jun 25, 2024, at 22:18, Mike Schinkel wrote: >> This leads me to think `strtok()` should not be deprecated given how >> inefficient string handling in PHP can otherwise be, at least not without a >> much more efficient object for string parsing