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

On Wed, Jun 26, 2024, at 23:42, Ilija Tovilo wrote: > > function test($value) { > if ($value is ['foo' => ?string]) { > $foo = $value['foo']; > } > } > test([]); (Scroll to the end if you don’t care about my rebuttal) I mean, there’s nothing wrong with this code, $foo will be nul

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

> On Jun 27, 2024, at 12:09 AM, Stephen Reay wrote: > > Hi Mike, > > To answer your question: I believe `abstract static` should be allowed, > because the "objection" mis-characterises a particular aspect of them as an > unintended consequence, when there's evidence to show that's not that ca

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

> On Jun 26, 2024, at 8:14 AM, Gina P. Banyard wrote: > > > On Wednesday, 26 June 2024 at 06:18, Mike Schinkel > wrote: >> https://3v4l.org/RDYFs#v8.3.8 >> >> Note those seven use-cases are found in around the first 25 results when >> searching GitHub for "str

[PHP-DEV] Allow int arguments for BCMath functions

Hi all! Gina suggest out that accept the BCMath\Number class as an argument to existing functions. This is difficult due to issues with dealing with scale, but I found that an int could be accepted. Without strict typing, if you pass an int to an existing bc function, it will be converted to

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

Hi Gina, > Apologies for the delay, to much traffic on the list so I forgot to address > this. Don’t worry! > >>> - 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 consid

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

On 2024-06-27 12:41, Chuck Adams wrote: There’s some difference though     [] is [?’foo’ => $x is string]              // matches, $x === null Except null is not a string. > There’s a precedent with function parameters: > > function foo(string $bar = null) // $bar is string|null > whi

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

On Tuesday, 25 June 2024 at 17:58, Saki Takamachi wrote: > Hi! > > This is a reminder as the feature freeze is approaching. I would like to > restate my current opinion. Apologies for the delay, to much traffic on the list so I forgot to address this. > > > - Suggestions for using 64-bit

Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages

On Wednesday, 26 June 2024 at 15:11, juan carlos morales wrote: > I also think it would be very useful to have better error messages. > > At the moment, we get things like "Syntax Error" ... period, no clue > where the JSON is corrupt or anything else. With big JSONs is very > cumberstone to ge

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

> On 27 Jun 2024, at 10:11, Mike Schinkel wrote: > > Hi Stephen, > >> On Jun 26, 2024, at 4:26 AM, Stephen Reay > > wrote: >> >> This is an example of code that works today (and all the way back to 5.0): >> https://3v4l.org/4EKo2 >> >> The class hierarchy em

Re: [PHP-DEV] Overriding GMP objects

Hi, > On Wednesday, 26 June 2024 at 18:24, Rob Landers wrote: >> Hello internals, >> >> I've had this little library for a while >> (https://github.com/withinboredom/time), mostly as a place to experiment >> with the quirks of PHP and take it in weird places. Anyway, I've been >> experimentin

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

On Tuesday, 25 June 2024 at 23:29, Bruce Weirdan wrote: > Is there a reason to keep crc32? Good question, I had a chat with Tim as I thought it was similar to the md5()/sha1() functions. Moreover, the crc32() function returns an int, whereas the equivalent of the hash extension returns a strin

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

On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela wrote: > I think the "Deprecate passing E_USER_ERROR to trigger_error()" should > be better explained. Why is using this constant a problem? There is a > link to another RFC, but I can't see an explanation as to why > E_USER_ERROR suffers the sam

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

On Wednesday, 26 June 2024 at 20:19, Morgan wrote: > I do not believe it is appropriate to deprecate strtok() without a proper > replacement. > > While I agree that its signature is undesirable, the suggested replacement > functions or “just write a parser” are not very pleasant solutions to fi

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

Hi Larry, > On Jun 26, 2024, at 2:21 PM, Larry Garfield > wrote: > PHP has no concept of packages at present, and thus no concept of > package-level scope. Not entirely true. PHP has static classes, which are stand-ins for packages for as long as PHP does not

Re: [PHP-DEV] Overriding GMP objects

On Wednesday, 26 June 2024 at 18:24, Rob Landers wrote: > Hello internals, > > I've had this little library for a while > (https://github.com/withinboredom/time), mostly as a place to experiment with > the quirks of PHP and take it in weird places. Anyway, I've been > experimenting with "stron

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

Hi Stephen, > On Jun 26, 2024, at 4:26 AM, Stephen Reay wrote: > > This is an example of code that works today (and all the way back to 5.0): > https://3v4l.org/4EKo2 > > The class hierarchy embody the type of classes this RFC is about: only static > members, no insta

[PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

Hello all. This is a ramble of an idea that's managed to run around my head for a few days now. It isn't fully formed, but I've ran the thought experiment as far as I can on my own and want to share it with all of you. I've mostly been a lurker and I've seen a lot of RFC's come and go. Of those no

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

> On Jun 26, 2024, at 5:49 PM, Derick Rethans wrote: > > There has been some work done on function autoloading too: > https://wiki.php.net/rfc/core-autoloading Fantastic! I still want modules and/or companion objects of course... I wonder whether the autoloading machinery could be bent to

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

On Wed, Jun 26, 2024 at 5:52 PM Derick Rethans wrote: > On Tue, 25 Jun 2024, Chuck Adams wrote: > > > > 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

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

> On Jun 26, 2024, at 1:50 PM, Morgan wrote: > So the issue has nothing to do with this hypothetical infinity of > unobservable nulls, and comes entirely down to the fact that with this > pattern a variable may pass > a) because it does not have a key named 'foo', or > b) because it has a key na

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

On Tue, 25 Jun 2024, Chuck Adams wrote: > > 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 b

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

On Wed, 26 Jun 2024, Lanre wrote: > That isn't a top post, look again. It was. If people point out you're doing something against this list's guidelines, don't reply with "it wasn't" in a snarky way. cheers, Derick

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

I suppose you don't actually need the `is` op; you can use the implements &| extends keywords :) Best, Richard Miles > On Jun 26, 2024, at 5:26 PM, Richard Miles wrote: > >> We've done some initial work related to this as part of PHP Foundation work: >>

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

> We've done some initial work related to this as part of PHP Foundation work: > After reviewing the PR I don't think this accurately captures what we're attempting to do/discuss. Are there other branches you could share

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

On Wed, Jun 26, 2024 at 3:27 PM Rob Landers wrote: > > > > On Wed, Jun 26, 2024, at 22:56, Casper Langemeijer wrote: > > > On Wed, Jun 26, 2024, at 21:59, Richard Miles wrote: > > I think we should have typed arrays in PHP. > > > Yes! I cannot stand sitting through conference talks on 'generics'

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

Several people said: > generics Is there a reason why traits can't be used to introduce generics? i.e. extending the code that composes the trait into the class to replace the generic type? eg. in `zend_add_trait_method`? (I couldn't quickly find where trait properties get added, even though my ex

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

Hey Derick, > A summary on the state of this, and actual genetics will be available soon > too. My mouth is watering already :) I have tons of free time at the moment if you’d like any help! Best, Richard Miles

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

On 26 June 2024 20:59:00 BST, Richard Miles wrote: >Howdy people, > >The pattern-matching RFC inspired me to write this. I have not done any work >for this yet; just looking for initial feedback. I think we should have typed >arrays in PHP. I propose adding the class SplTypeDefinedArray. We've

Fwd: [PHP-DEV] [Initial Feedback] Typed Arrays

I actually do like the idea of Generics, but the more I think about it, it's not the problem here. Everyone should absolutely catch up on Larry Garfield’s Pattern Matching RFC. It could be the key for generics (the is operator). The problem is making "array interfaces" a thing. Larry said he pro

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

Hi Rob On Wed, Jun 26, 2024 at 10:36 PM Rob Landers wrote: > >> On Wed, Jun 26, 2024, at 21:50, Morgan wrote: >> >> So the issue has nothing to do with this hypothetical infinity of >> unobservable nulls, and comes entirely down to the fact that with this >> pattern a variable may pass >> a) beca

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

On Wed, Jun 26, 2024, at 22:56, Casper Langemeijer wrote: > > On Wed, Jun 26, 2024, at 21:59, Richard Miles wrote: >> I think we should have typed arrays in PHP. > > Yes! I cannot stand sitting through conference talks on 'generics' that only > talk about 'collections'. This could be solved

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

On Wed, Jun 26, 2024 at 3:10 PM Bilge wrote: > On 26/06/2024 21:56, Casper Langemeijer wrote: > > Generics or bust. > > > I do not understand the reasoning behind that. Is it because we really > want generics, but when the 95% use-case is solved we fear that there would > not be enough momentum

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

I wonder if this could be helpful in implementing Generic Classes? https://wiki.php.net/rfc/generics Interface Boxable {...} class Box {...} Taken from the RFC ^ Best, Richard Miles

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

On Tue, Jun 4, 2024, at 14: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] [Initial Feedback] Typed Arrays

On 26/06/2024 21:56, Casper Langemeijer wrote:  Generics or bust. I do not understand the reasoning behind that. Is it because we really want generics, but when the 95% use-case is solved we fear that there would not be enough momentum to get that? I'd love to have generics too, but a very s

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

On Wed, Jun 26, 2024, at 21:59, Richard Miles wrote: > I think we should have typed arrays in PHP. Yes! I cannot stand sitting through conference talks on 'generics' that only talk about 'collections'. This could be solved if we had typed arrays. If anything we would get better talks on Gener

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

I looked online, and I see two RFC’s relating to generics. One talks about arrays specifically. https://wiki.php.net/rfc/generics https://wiki.php.net/rfc/generic-arrays I don’t think that it gives the full power we’re looking for, and also not sure where the work at on these either. Would

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

On Wed, Jun 26, 2024, at 21:50, Morgan wrote: > On 2024-06-26 09:58, Rob Landers wrote: > > On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote: > >> > >> > >> It may be questionable to give meaning to the difference in some of > >> these cases, but different it definitely is. > > > > Tru

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

Also I specifically said "we can declare functions that are local to the current file by not exporting them.", Where did you get "package private" from? On Wed, Jun 26, 2024 at 1:46 PM Larry Garfield wrote: > On Wed, Jun 26, 2024, at 6:05 PM, Lanre wrote: > > In JavaScript/Typescript, we can dec

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

That isn't a top post, look again.And I am not referring to packages,rather to the ability to define functions that aren't exposed to the users of a library. C doesn't have packages either yet this is possible in it. And marking it as internal is not the same thing at all. I am not going to argue a

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

On 25/06/2024 16:17, Derick Rethans wrote: we shouldn't be encouraging static classes as a bag of static functions, that ought to be just namespaced functions. I understand this is the prevailing preference of a certain few, including (but not limited to) yourself and Larry. Nevertheless, clas

Re: [PHP-DEV] [Initial Feedback] Typed Arrays

On 26/06/2024 20:59, Richard Miles wrote: I think we should have typed arrays in PHP. Generics or bust. Cheers, Bilge

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

Hi Gina, On Tue, Jun 25, 2024 at 5:59 PM Gina P. Banyard wrote: > The fact that an initialize() method has a $skipInitializer parameter > doesn't make a lot of sense to me. > Because at a glance, I don't see how passing true to it, and not calling > the method is different? > Calling initialize

[PHP-DEV] [Initial Feedback] Typed Arrays

Howdy people, The pattern-matching RFC inspired me to write this. I have not done any work for this yet; just looking for initial feedback. I think we should have typed arrays in PHP. I propose adding the class SplTypeDefinedArray. A few considerations: A new syntax allowing Array interfaces w

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

On 2024-06-26 09:58, Rob Landers wrote: On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote: It may be questionable to give meaning to the difference in some of these cases, but different it definitely is. True, but I was mainly referring to what you would do after performing an 'i

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

I do not believe it is appropriate to deprecate strtok() without a proper replacement. While I agree that its signature is undesirable, the suggested replacement functions or “just write a parser” are not very pleasant solutions to fill the void it would leave. The stateful functionality it exhib

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

Juliette Reinders Folmer said: > Not a fan of using a variable as a return type. This will cause > havoc for Tokenizer based static analysis tooling. I will concede that until the tools are updated to handle the new (currently invalid) syntax, it would cause issues. But that happens everytime a ne

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

Hi Levi, On Wed, Jun 26, 2024 at 12:07 AM Levi Morrison wrote: > I will vote no on this one. I do not believe the internal complexity > and maintenance is worth the feature. Additionally, I do not feel like > changing the language to support this feature is a good idea; if this > were a library

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

On Wed, Jun 26, 2024, at 19:57, Richard Miles wrote: > “Array-application will also be pushed to future-scope” > > > Dang, this is what I was looking forward to the most. Helping set some > precedent on this issue, and this is a solid start. I’ve been thinking about > what it would look like fo

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

On Wed, Jun 26, 2024, at 6:05 PM, Lanre wrote: > In JavaScript/Typescript, we can declare functions that are local to > the current file by not exporting them. In C/C++ this is achieved by > simply writing the function in the implementation file as opposed to > the header. However, achieving a s

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

After a coffee break, I think this is how the language could do this in a semantically pleasing way. interface iArrayA ['a' => string ] interface iArrayB extends iArrayA ['b' => string ] $arr is iArrayA &| iArrayB Best, Richard Miles > On Jun 26, 2024, at 11:57 AM, Richard Miles wrote: > >

Re: [PHP-DEV] Overriding GMP objects

I am interested to see what people say to this. One of the primary reasons I was given by no voters on my operator overload RFC was that it was not useful enough to justify the complexity. Since then however we have had a steady stream of people on list presenting their use cases that have run into

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

In JavaScript/Typescript, we can declare functions that are local to the current file by not exporting them. In C/C++ this is achieved by simply writing the function in the implementation file as opposed to the header. However, achieving a similar level of privacy in PHP requires using private stat

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

“Array-application will also be pushed to future-scope” Dang, this is what I was looking forward to the most. Helping set some precedent on this issue, and this is a solid start. I’ve been thinking about what it would look like for strictly typed arrays in PHP for a while now. I think a custom

[PHP-DEV] Overriding GMP objects

Hello internals, I've had this little library for a while (https://github.com/withinboredom/time), mostly as a place to experiment with the quirks of PHP and take it in weird places. Anyway, I've been experimenting with "strongly typed time" in attributes for a while now. At this point, it's a

Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages

On Wed, Jun 26, 2024, at 2:11 PM, juan carlos morales wrote: > Hello Internals. > > I'm here to discuss an improvement in error messages when dealing with > JSON in PHP. > > After watching Derick Rethans speak at the UK PHP Conference: > > https://youtu.be/3U0DGhzSH2U?feature=shared&t=2483 > > I al

[PHP-DEV] [RFC][Discussion] Enhance JSON error messages

Hello Internals. I'm here to discuss an improvement in error messages when dealing with JSON in PHP. After watching Derick Rethans speak at the UK PHP Conference: https://youtu.be/3U0DGhzSH2U?feature=shared&t=2483 I also think it would be very useful to have better error messages. At the momen

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

I think the "Deprecate passing E_USER_ERROR to trigger_error()" should be better explained. Why is using this constant a problem? There is a link to another RFC, but I can't see an explanation as to why E_USER_ERROR suffers the same problem as fatal errors do. From an average Joe's perspective, it

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

On 26 June 2024 09:23:42 BST, Rob Landers wrote: > >It will always output that warning, regardless of strict types, but as this >thread has already covered numerous times, it is unobservable from the >executing code unless you turn the warning into an exception. I think this conversation is

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

Hi Marco, Benjamin, > As for tuple vs reference, I think the general direction is to move away from > references as much as possible, and AFAIK references actually make things > harder for IDEs and static analysis tools, whereas the tuple syntax > array{string, string} is well understood at lea

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

On Wednesday, 26 June 2024 at 06:39, Dusk wrote: > On Jun 25, 2024, at 22:18, Mike Schinkel m...@newclarity.net 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 effici

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

On Wednesday, 26 June 2024 at 06:18, Mike Schinkel wrote: >> https://3v4l.org/RDYFs#v8.3.8 > > Note those seven use-cases are found in around the first 25 results when > searching GitHub for "strtok(". I could probably find more if I kept looking: > >> https://github.com/search?q=strtok%28+langu

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

On 2024-06-24 01:10, Bilge wrote: I am pleased to present my first RFC: Static class . Just one point of feedback: for clarity I think it would be good if it mentions that creating dynamic properties i.e. $this->dynamicProp = 'bar' would also throw at runt

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

> On 26 Jun 2024, at 12:51, Mike Schinkel wrote: > >> 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 >

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

On Wed, Jun 26, 2024, at 10:11, Arvids Godjuks wrote: > > > On Wed, 26 Jun 2024 at 11:00, Rob Landers wrote: >> __ >> >> >> On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote: >>> >>> >>> On Wed, Jun 26, 2024, at 00:19, Morgan wrote: On 2024-06-26 08:24, Rob Landers wrote: > On Tu

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

On Wed, 26 Jun 2024 at 11:00, Rob Landers wrote: > > > On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote: > > > > On Wed, Jun 26, 2024, at 00:19, Morgan wrote: > > 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 inde

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

On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote: > > > On Wed, Jun 26, 2024, at 00:19, Morgan wrote: >> 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

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

On Wed, Jun 26, 2024, at 00:19, Morgan wrote: > 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