Re: [PHP-DEV] Concept: Lightweight error channels

> What's the problem with PHP exceptions? I'm not even trying to argue, I'm > trying to understand. Is it the implementation (bad/expensive performance)? > Semantics? Handling syntax? Larry provided several problems in the opening of his email; you may want to reread that. I will affirm that exce

RE: [PHP-DEV] Concept: Lightweight error channels

Hi, Reading this as a PHP dev is confusing (terminology-wise) because errors used to be the fatal ("stop the world") conditions while exceptions were the catchable, recovarable issues within some call - feels to me pretty equivalent to what you're proposing here. What's

Re: [PHP-DEV] Concept: Lightweight error channels

On Sat, Apr 26, 2025, at 09:17, Larry Garfield wrote: > Hi folks. In several recent RFCs and related discussion, the question of > error handling has come up. Specifically, the problem is: > > * "return null" conflicts with "but sometimes null is a real value" (the > validity of that positio

[PHP-DEV] Concept: Lightweight error channels

Hi folks. In several recent RFCs and related discussion, the question of error handling has come up. Specifically, the problem is: * "return null" conflicts with "but sometimes null is a real value" (the validity of that position is debatable, but common), and provides no useful information a

[PHP-DEV] PHP 8.3.21RC1 available for testing

PHP 8.3.21RC1 has just been released and can be downloaded from: https://downloads.php.net/~eric/ or https://qa.php.net/ or use the git tag: php-8.3.21RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.3 Please test it carefully, and report any bugs to https://github.c

Re: [PHP-DEV] Re: RFC: Nested Classes

On Thu, Apr 24, 2025, at 17:20, Tim Düsterhus wrote: > Hi > > On 4/24/25 17:09, Rob Landers wrote: > > Thank you for your feedback! I think you would then have the problem that > > was pointed out by Levi the other day; where you would then have ambiguity. > > If you could have both private an

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/20/25 15:43, Rob Landers wrote: As it seems that discussion has mostly died down, I'd like to put this towards a vote starting on May 1, 2025. Unfortunately I did not have the time to follow the discussion after mid-March, so this might or might not have been discussed already. I ju

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/24/25 17:09, Rob Landers wrote: Thank you for your feedback! I think you would then have the problem that was pointed out by Levi the other day; where you would then have ambiguity. If you could have both private and public names in the same namespace, then you would end up not knowin

Re: [PHP-DEV] Re: RFC: Nested Classes

On Thu, Apr 24, 2025, at 16:31, Tim Düsterhus wrote: > Hi > > On 4/20/25 15:43, Rob Landers wrote: > > As it seems that discussion has mostly died down, I'd like to put this > > towards a vote starting on May 1, 2025. > > Unfortunately I did not have the time to follow the discussion after >

Re: [PHP-DEV] DokuWiki password reset failed?

Aside, shouldn't we have a separate mailing list for admin tasks? e.g. RFC karma, etc.

[PHP-DEV] PHP 8.4.7RC1 available for testing

Hi all! PHP 8.4.7RC1 has just been released and may be downloaded from https://downloads.php.net/~saki/ Or use the git tag: php-8.4.7RC1 Windows binaries are available at: https://windows.php.net/qa/ Please test it carefully, and report any bugs at https://github.com/php/php-src/issues 8.4.7

Re: [PHP-DEV] DokuWiki password reset failed?

> On Apr 24, 2025, at 04:32, Christoph M. Becker wrote: > > On 24.04.2025 at 03:21, Paul M. Jones wrote: > >> I just reset my `pmjones` password on DokuWiki, but the password it sent is >> not letting me in. Is there something else I need to do? > > Since you have a php.net account, this on

Re: [PHP-DEV] DokuWiki password reset failed?

On 24.04.2025 at 03:21, Paul M. Jones wrote: > I just reset my `pmjones` password on DokuWiki, but the password it sent is > not letting me in. Is there something else I need to do? Since you have a php.net account, this one is used for the DokuWiki login as well. Did you forget your php.net pa

[PHP-DEV] DokuWiki password reset failed?

Hi all, I just reset my `pmjones` password on DokuWiki, but the password it sent is not letting me in. Is there something else I need to do? Sorry for the hassle, and thanks for your patience. -- pmj

Re: [PHP-DEV] [RFC] [Vote] array_first() and array_last()

On Tue, Apr 22, 2025 at 9:18 PM Niels Dossche wrote: > > Hi internals > > I'm opening the vote for https://wiki.php.net/rfc/array_first_last > Vote runs until 2025-05-06 23:59:59 CEST. > > Kind regards > Niels I've voted yes. I still don't like functions which conflate null as an error and null a

Re: [PHP-DEV][Pre-RFC] Associated Types

On 22 April 2025 14:37:48 BST, "Gina P. Banyard" wrote: >Having talked with Arnaud off-list, it seems that using the "usual" generic >syntax of (assuming our parser can cope with it): >``` >interface I { >public function foo(T $param): T; >} >class CS implements I { >public function fo

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

Hi Am 2025-04-17 13:18, schrieb Máté Kocsis: Sweet. I believe this was/is the last remaining blocker for the RFC or is there still anyone else from your side that needs to be discussed? I need to give the RFC another read once you made the adjustment to remove the WhatWg raw methods (and adju

Re: [PHP-DEV][Pre-RFC] Associated Types

On Tue, 22 Apr 2025 at 19:39, Gina P. Banyard wrote: > > Hello internals, > > The discussion about allowing never types as parameter types made me think > about what problem it is truly trying to solve, > which is using the same type as parameters and return values between multiple > methods of

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On Sun, Apr 20, 2025 at 9:30 AM Niels Dossche wrote: > > On 05/04/2025 17:51, Niels Dossche wrote: > > Hi internals > > > > I'm opening the discussion for the RFC "array_first() and array_last()". > > https://wiki.php.net/rfc/array_first_last > > > > Kind regards > > Niels > > > > > Hi > > I'll be

[PHP-DEV] Re: Sentential Entity 6.5 - Mine and Sparx lastest OS based in Ubuntu but an enliving machine (Something to also forward on)

For Recommending to people please read the manuals + guides:~ extract Sentential Entity 6.5 AMD64 Manuals as Tiesaa Binders extract Sentential Entity 6.5 AMD64 Guides as Tiesaa Binders extract Sentential Entity 6.5 ARM64 Manuals as Tiesaa Binders extract Sentential Entity 6.5 ARM64 Guides as Tiesa

Re: [PHP-DEV][Pre-RFC] Associated Types

On Tue, Apr 22, 2025, at 8:37 AM, Gina P. Banyard wrote: > Hello internals, > > The discussion about allowing never types as parameter types made me > think about what problem it is truly trying to solve, > which is using the same type as parameters and return values between > multiple methods of

[PHP-DEV] [RFC] [Vote] array_first() and array_last()

Hi internals I'm opening the vote for https://wiki.php.net/rfc/array_first_last Vote runs until 2025-05-06 23:59:59 CEST. Kind regards Niels

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Tue, Apr 22, 2025, at 19:22, Levi Morrison wrote: > On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote: > > > > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > > > > Hello internals, > > > > I have significantly revamped the RFC (again). Key changes to the RFC: > > > > 1. More (realistic)

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote: > > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > > Hello internals, > > I have significantly revamped the RFC (again). Key changes to the RFC: > > 1. More (realistic) examples, > 2. Since enums are basically specialized classes, they are a

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 22/04/2025 18:51, Levi Morrison wrote: > I don't think it blocks this RFC in any way, and could be made > frameless after the vote--I just wanted to bring up that I think > they _should_ be frameless if they get accepted (and update > array_key_first/array_key_last to be frameless too). Hi Ind

[PHP-DEV][Pre-RFC] Associated Types

Hello internals, The discussion about allowing never types as parameter types made me think about what problem it is truly trying to solve, which is using the same type as parameters and return values between multiple methods of a common interface. This is normally solved with generics, but as

[PHP-DEV] Sentential Entity 6.5 - Mine and Sparx lastest OS based in Ubuntu but an enliving machine (Something to also forward on)

Okey on extract on the timing bells which is where you or your lawyer in the justice system runs the print command to get and install books etc, also in your push you can get these iso if you can store it, Sentential Entity is our new operating system, which is also an enliving enreal machine like

[PHP-DEV] New Extensions: All Completely United Tested + Developed:: Backdated PHP Versions to Current::: For mounting on github.com

To PHP.net, How are you? I have some extensions for you to mount on github.com you also need a sourceforge.net as it is the only way of supporting the Source-code: //sourceforge.net/p/php-net call in stien systems; the only place that supports the Source-code header call is sourceforge.net; they a

Re: [PHP-DEV] [VOTE] Never parameters (v2)

Hey Daniel, I'm currently planning to vote "no" on this. The reason is that I see this RFC as very narrowly scoped on constructors / named constructors, and only in the case where a concrete class is referenced by a consumer. Constructors/named constructors are effectively not part of an object'

[PHP-DEV] [VOTE] Never parameters (v2)

Hi internals, I have opened the vote on https://wiki.php.net/rfc/never-parameters-v2. The vote will run for 2 weeks (and a few hours), closing on May 5th at the end of the day (UTC). --Daniel

[PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 05/04/2025 17:51, Niels Dossche wrote: > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels > Hi I'll be putting this to vote on Tuesday 22nd if no one has complaints. Kind regards

[PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > Hello internals, > > I have significantly revamped the RFC (again). Key changes to the RFC: > > 1. More (realistic) examples, > 2. Since enums are basically specialized classes, they are allowed to be > nested as well (hat tip to Reddit), > 3.

[PHP-DEV] Re: Declaration-aware attributes

To follow up on this idea. A less problematic solution would be to have a global function or static method similar to func_get_args(), that can only be called from within the constructor of an attribute. A function would be the most natural. But if we are afraid of name clashes with userland funct

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

On Sat, Apr 19, 2025 at 6:02 AM Pierre Joye wrote: > On Fri, Apr 18, 2025 at 11:41 PM Jakub Zelenka wrote: > > > That said we also need to think about the project and possible risk that > this can also bring. One of those is potentially hiding the identity > because the author does not have righ

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

On Fri, Apr 18, 2025 at 11:41 PM Jakub Zelenka wrote: > > Hi, > > We just had some private discussions about the implication of contributing > under pseudonym. This is in general fine and we should not have problem with > it and we actually never verified the contributors so this is possibly >

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

Hi On Fri, Apr 18, 2025 at 9:04 PM Sai Liu wrote: > > > Jakub Zelenka hat am 18.04.2025 18:37 CEST geschrieben: > > > Hi, > > We just had some private discussions about the implication of contributing > under pseudonym. This is in general fine and we should not have problem > with it and we act

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

On Fri, Apr 18, 2025 at 7:53 PM Niels Dossche wrote: > Hi > > I have a strong suspicion of why this comes up now, but would still like > to have more openness on why this is suddenly needed. > This just seems like an extra barrier and extra work. > Since this is a policy change, doesn't this need

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

  Jakub Zelenka hat am 18.04.2025 18:37 CEST geschrieben:     Hi,   We just had some private discussions about the implication of contributing under pseudonym. This is in general fine and we should not have pro

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

On 18/04/2025 20:10, Marco Aurélio Deleu wrote: > One can argue that this isn’t a policy change but rather just tooling to help > enforce a policy already in place:  > https://www.php.net/license/contrib-guidelines-code.php > Hi Are you

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

Marco Deleu > On 18 Apr 2025, at 14:54, Niels Dossche wrote: > > Hi > > Since this is a policy change, doesn't this need an RFC as well? > > Kind regards > Niels One can argue that this isn’t a policy change but rather just tooling to help enforce a policy already in place: https://www.p

Re: [PHP-DEV] Requiring DCO (Developer Certificate of Origin)

Hi I have a strong suspicion of why this comes up now, but would still like to have more openness on why this is suddenly needed. This just seems like an extra barrier and extra work. Since this is a policy change, doesn't this need an RFC as well? Kind regards Niels

Re: [PHP-DEV] PHP True Async RFC Stage 3

Hi Edmond! On Wed, Apr 16, 2025 at 7:02 AM Edmond Dantes wrote: > Good day, everyone. I hope you're doing well. > > I’d like to introduce the RFC for the True Async component. > > https://wiki.php.net/rfc/true_async > > This time the work took longer because I was exploring different > architect

Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

2025年4月17日(木) 16:16 Tim Düsterhus : > > Hi > > Am 2025-04-16 02:40, schrieb youkidearitai: > > The RFC for add grapheme_levenshtein function has been accepted. > > (Yes 12 / No 0) > > > > Thank you very much for voting. > > I will go to implementation. > > Great, thank you! I noticed that while you

[PHP-DEV] Requiring DCO (Developer Certificate of Origin)

Hi, We just had some private discussions about the implication of contributing under pseudonym. This is in general fine and we should not have problem with it and we actually never verified the contributors so this is possibly happening already. The only thing about it is that it might raise ques

Re: [PHP-DEV] PHP True Async RFC Stage 3

Good day, Deleu! > What happens if the coroutine didn't finish execution? does `disposeSafely()` means that it will wait until completion to safely clear it up or does it mean it will attempt to dispose and throw an exception if it fails to do so? Cooperative cancellation implies that a coroutine

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

Hi Maté and all, A one-off comment about the exceptions: The RFC posits that _Uri\UriException_ extends _Exception_, and _Uri\InvalidUriException_ extends _UriException_. However, pre-existing userland solutions to the URI problem lean more heavily on the native PHP _InvalidArgumentException_,

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

Hi On 4/17/25 23:14, Paul M. Jones wrote: On 4/17/25 22:47, Paul M. Jones wrote: As such, the _InvalidUriException_ would better extend from _LogicException_. No. There is a de facto policy of “not using SPL exceptions in new code”. The replacement for LogicException is the Error hierarchy.

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

> On Apr 17, 2025, at 15:58, Tim Düsterhus wrote: > > Hi > > On 4/17/25 22:47, Paul M. Jones wrote: >> As such, the _InvalidUriException_ would better extend from _LogicException_. > > No. There is a de facto policy of “not using SPL exceptions in new code”. The > replacement for LogicExcep

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

Hi On 4/17/25 22:47, Paul M. Jones wrote: As such, the _InvalidUriException_ would better extend from _LogicException_. No. There is a de facto policy of “not using SPL exceptions in new code”. The replacement for LogicException is the Error hierarchy. Also, as you quoted yourself, LogicExc

Re: [PHP-DEV] PHP True Async RFC Stage 3

Hello, Rowan! > I don't have time to dig into the details of this draft at the moment, but will say that a vote in two weeks is not at all realistic. I just used the Flow from the Wiki. :) > My only other comment at a very quick glance is that I see the Context section is still included, and stil

Re: [PHP-DEV] VCS Account Request: edorian

On 17.04.2025 at 17:23, Volker Dusch wrote: > Release Manager Duties, see: https://externals.io/message/127025#127131 Your account request has been approved. Congrats for being one of the new RMs! Christoph

[PHP-DEV] VCS Account Request: edorian

Release Manager Duties, see: https://externals.io/message/127025#127131

Re: [PHP-DEV] PHP True Async RFC Stage 3

On 17 April 2025 09:54:26 BST, Edmond Dantes wrote: >> My only other comment at a very quick glance is that I see the Context >section is still included, and still has most of its complexity. >Almost every section of the RFC has a "Motivation" subsection, which >explains why a particular tool i

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

Hi Ignace, > Currently the path is nullable but according to the RFC the path can not > be nullable > According to the RFC the path can have up to 5 ABNF representation > Uh, this is something that I also forgot to sync between the implementation and the RFC. I also recently found out that the g

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

Hi Ignace, > Uh, this is something that I also forgot to sync between the > implementation and the RFC. I also recently found out that > the get*Path() methods should be non-nullable for both classes, so I > recently fixed them. Sorry for the confusion! > Actually, I realized after checking the

Re: [PHP-DEV] PHP True Async RFC Stage 3

Hello, Vincent. > The `spawn` keyword might disqualify this rfc, i talked to alot of php devs about this rfc and they all had a similar complaint about the keyword, maybe a keyword choice poll might help when the rfc voting goes live. To have any kind of vote, we need multiple options. The keywor

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

I still have one last question regarding the RFC3986 URI path component. Currently the path is nullable but according to the RFC the path can not be nullable According to the RFC the path can have up to 5 ABNF representation > path = path-abempty ; begins with "/" or is empty

Re: [PHP-DEV] PHP True Async RFC Stage 3

Here are list of the problems i saw in this RFC: 1.) The `spawn` keyword might disqualify this rfc, i talked to alot of php devs about this rfc and they all had a similar complaint about the keyword, maybe a keyword choice poll might help when the rfc voting goes live. 2.) This whole rfc seem a l

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

Hi, Tim Düsterhus ezt írta (időpont: 2025. ápr. 17., Cs, 9:22): > Hi > > Am 2025-04-15 23:55, schrieb Máté Kocsis: > > This was one of my (unspoken) ideas as well. I used to think there must > > have been a correct logic > > for percent-decoding of WHATWG components, but if none of us can come

Re: [PHP-DEV] [VOTE] PHP 8.5 Release Managers

Hi all, The polls have closed, and Derick’s scripts have tallied the votes [1], Our “rookie" PHP 8.5 release managers are: - Volker Dusch - Daniel Scherzer Our "veteran” is the PHP 8.2 & PHP 8.3 release manager Pierrick Charron, Volker and Daniel you are in a good hands! Further steps are desc

Re: [PHP-DEV] PHP True Async RFC Stage 3

> The link in Patches and Tests is currently giving a 404 Not Found. > Can you update the link to your proof of concept implementation? Thank you for pointing that out. I’ve corrected the link. https://github.com/EdmondDantes/php-src/tree/async/ext/async

Re: [PHP-DEV] RFC: blank() Function as a Complement to empty()

Hi Am 2025-04-07 09:14, schrieb Rowan Tommins [IMSoP]: I think a function for "string is zero length or contains only whitespace" would potentially be useful And for that one it would need to be defined what whitespace is. Is it just the ASCII whitespace characters? Is it Unicode whitespace?

Re: [PHP-DEV] New max_memory_limit INI setting

Hi Am 2025-04-15 10:13, schrieb Jordi Boggiano: I'd say absolutely yes it should respect the requested memory limit as much as possible. Especially when setting memory_limit to -1 you'd definitely want this to mean "use the max allowed memory limit" and perhaps even skip the warning in that

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

Hi Am 2025-04-15 23:55, schrieb Máté Kocsis: This was one of my (unspoken) ideas as well. I used to think there must have been a correct logic for percent-decoding of WHATWG components, but if none of us can come up with a sensible idea, then it's best not to try it, I agree. Sweet. I believ

Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

Hi Am 2025-04-16 02:40, schrieb youkidearitai: The RFC for add grapheme_levenshtein function has been accepted. (Yes 12 / No 0) Thank you very much for voting. I will go to implementation. Great, thank you! I noticed that while you updated the status in the RFC itself, you did not update the

Re: [PHP-DEV] PHP True Async RFC Stage 3

The link in Patches and Tests is currently giving a 404 Not Found. Can you update the link to your proof of concept implementation?

Re: [PHP-DEV] PHP True Async RFC Stage 3

On 16 April 2025 10:59:25 BST, Edmond Dantes wrote: >Good day, everyone. I hope you're doing well. > >I’d like to introduce the RFC for the True Async component. > >https://wiki.php.net/rfc/true_async > > This RFC will go to a vote in about two weeks. Hi Ed, I don't have time to dig into the

Re: [PHP-DEV] PHP True Async RFC Stage 3

is "True Async" a fancy way of saying multithreading? Seems like a threading api to me

[PHP-DEV] PHP True Async RFC Stage 3

Good day, everyone. I hope you're doing well. I’d like to introduce the RFC for the True Async component. https://wiki.php.net/rfc/true_async This time the work took longer because I was exploring different architectural options and paid more attention to how it works in other languages. I was

Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

2025年4月1日(火) 13:39 youkidearitai : > > Hi, internals. > > I started vote to RFC grapheme_levenshtein > RFC: https://wiki.php.net/rfc/grapheme_levenshtein > > Voting end is 2025-04-16 00:00:00(UTC+0). > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh

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

Hi Tim, > Perhaps the correct solution would be to offer only the non-raw methods > for WHATWG URL and to not attempt any additional percent-decoding there? > My reasoning is that the WHATWG URL is a living standard anyways, so > trying to add additional semantics on top will result in sadness. M

Re: [PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer wrote: > > On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer > wrote: >> >> >> Since a lot of the discussion seems to be around static analysis and whether >> there is a real use case for this, I wanted to share another use case I just >> came across:

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer wrote: > > Since a lot of the discussion seems to be around static analysis and > whether there is a real use case for this, I wanted to share another use > case I just came across: in the `thephpleague/commonmark` package, > different renderers are

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

Perhaps the correct solution would be to offer only the non-raw methods for WHATWG URL and to not attempt any additional percent-decoding there? My reasoning is that the WHATWG URL is a living standard anyways, so trying to add additional semantics on top will result in sadness. My understandin

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

Hi Am 2025-04-13 14:10, schrieb Máté Kocsis: namespace Uri { class InvalidUriException extends \Uri\UriException { } } namespace Uri\WhatWg { class InvalidUrlException extends \Uri\InvalidUriException { /** @var list */

Re: [PHP-DEV] Closure::getCurrent() for recursion

On 15/04/2025 11:49, Jorg Sowa wrote: I gave this example only to point out that this case should be mentioned in the RFC to dispel doubts what's intended and eventually put such test case into the PR. Sure, but there was a mistake in your example - Closure::current(10) should be Closure::cu

Re: [PHP-DEV] Closure::getCurrent() for recursion

I gave this example only to point out that this case should be mentioned in the RFC to dispel doubts what's intended and eventually put such test case into the PR. Kind regards, Jorg

Re: [PHP-DEV] New max_memory_limit INI setting

On 14.04.2025 14:41, Ilija Tovilo wrote: One open question is whether exceeding the max_memory_limit should also set memory_limit to max_memory_limit in addition to warning, giving the subsequent operation a higher chance not to straight out OOM error. Let me know if you have a preference in that

Re: [PHP-DEV] Closure::getCurrent() for recursion

On 15 April 2025 00:01:18 BST, Krinkle wrote: >Eg: > >$a = function ($a) { > $aFn = Closure::current(...); > $aFn(4) === Closure::current(4); >}; I think there's some confusion on this thread; as I understand it, the proposal is not for a magic function to *call* the current closure, but a w

Re: [PHP-DEV] Closure::getCurrent() for recursion

On Mon, 31 Mar 2025, Jorg Sowa wrote: > I thought about edge cases and what the desired output is with nested > closures? > > Example: > $a = function (int $numberA) { > $b = function (int $numberB) { > if($numberB < 10) { > return Closure::current(10); > } >

[PHP-DEV] New max_memory_limit INI setting

Hi everyone We've received a PR from Frederik Pytlick (@frederikpyt, thank you!) that introduces a new max_memory_limit INI setting. https://github.com/php/php-src/pull/18011 This setting declares an upper bound for memory_limit, which will prevent memory_limit from being set to a value higher t

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Hi, On Sun, Apr 13, 2025 at 11:09 PM Jorg Sowa wrote: > Thank you all for the feedback on the topic of BC breaks in argument > validation https://news-web.php.net/php.internals/126706 > > I have collected all concerns, prepared an RFC for this change, and I'm > opening discussion on its content:

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Hey Jorg, On 13.4.2025 23:07:07, Jorg Sowa wrote: I have collected all concerns, prepared an RFC for this change, and I'm opening discussion on its content: https://wiki.php.net/rfc/minor-version-compatibility Let me address some parts of the RFC: - The secondary vote #1 requires the same h

[PHP-DEV] [RFC] [Discussion] Minor version compatibility

Thank you all for the feedback on the topic of BC breaks in argument validation https://news-web.php.net/php.internals/126706 I have collected all concerns, prepared an RFC for this change, and I'm opening discussion on its content: https://wiki.php.net/rfc/minor-version-compatibility Since this

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On 13/04/2025 15:07, Kamil Tekiela wrote: This discussion seems to have overlooked that the setting doesn't just restrict the*display* of arguments, it restricts the*collection* of those arguments into the Exception object, which has visible effects on the behaviour and performance of the program

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

>This discussion seems to have overlooked that the setting doesn't just restrict the *display* of arguments, it restricts the *collection* of those arguments into the Exception object, which has visible effects on the behaviour and performance of the program. Oh, I didn't know that. I assumed the

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

Hi Tim, I think I would prefer: > > namespace Uri { > class InvalidUriException extends \Uri\UriException > { > } > } > > namespace Uri\WhatWg { > class InvalidUrlException extends \Uri\InvalidUriException { > /** @var list */ >

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On 09/04/2025 03:00, Andrew Lyons wrote: Hi everyone, I've been working on a new RFC which proposes changing the default value for the zend.exception_ignore_args INI setting from Off to On. The intent of this change is to make PHP installations safer by default and prevent the accidental rel

Re: [PHP-DEV] mysqli_fetch_all(MYSQLI_OBJECT)

Thanks for sharing it. This begins to look a lot like the nasty overloaded PDOStatement::fetchAll. It would also be nice to have fetch_all for a single column, and then we have it. I'd rather we avoid that if we want to expand mysqli functionalities. How about adding mysqli_fetch_all_object? No ne

Re: [PHP-DEV] mysqli_fetch_all(MYSQLI_OBJECT)

On Sunday, 23 February 2025 at 02:57:07 GMT, Gareth Peters wrote: Hi all I've written code to expand the functionality of mysqli_fetch_all. It allows you to fetch all results as objects rather than just arrays. It has the same features as fetch_object, such as being able to specify the name of

Re: [PHP-DEV] Consensus on argument validation for built-in functions

Thank you all for inputs. There is no consensus at all, so we must go through RFC process. I will sum up feedback and I will create the RFC this weekend. Kind regards, Jorg

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

> In an ideal world they are never revealed to the end user, but real-world solutions fall short. It's not uncommon for people to have display_errors enabled for some reason or another. It is also possible for sites to be misconfigured, or for applications to make mistakes and accidentally dump sta

Re: [PHP-DEV] Consensus on argument validation for built-in functions

> > > This thread clearly shows that there is no consensus so I think the only > way forward would be to create a policy RFC to make decision about this > approach. Until then no PR introducing exception, deprecation or just plain > warning for this sort of things should be merged. > > In terms of

Re: [PHP-DEV] Consensus on argument validation for built-in functions

Hi, On Tue, Mar 11, 2025 at 12:09 AM Jorg Sowa wrote: > Hello everyone, > > I’d like to align on the approach to validating arguments for built-in > functions (usually for flag inputs). Some ongoing discussions in PRs: > - https://github.com/php/php-src/pull/15647 > - https://github.com/php/php-

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

> I can't find any information on why this setting was introduced. No, I couldn't find anything either. I did try to investigate and all I could find was that it was introduced by Joe Watkins in 0819e6dc9b4788e5d44b64f8e606a56c969a1588 in 2019 but I haven't been able to find any history of RFC or

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

> > Full agreement with Tim here - make PHP friendly to development. Generally I do agree with this sentiment. Languages should be developer-friendly, but not at the expense of safety. Developers are able to configure an INI setting in multiple ways including modifying an ini file, using the `ini

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

On Thu, 10 Apr 2025 at 23:20, Tim Düsterhus wrote: > As I had said on GitHub before, but to put it onto the list for > visibility: > > I'd rather see the value in `php.ini-production` being changed to `Off` > to match the built-in default. see > https://github.com/php/php-src/pull/18215#issuecomme

Re: [PHP-DEV] [RFC] Pipe Operator (again)

Hi Larry Sorry again for the delay. On Fri, Apr 4, 2025 at 6:37 AM Larry Garfield wrote: > > * A new iterable API is absolutely a good thing and we should do it. > * That said, we *need* to split Sequence, Set, and Dictionary into separate > types. We are the only language I reviewed that didn

[PHP-DEV] PHP 8.4.6 Released

The PHP development team announces the immediate availability of PHP 8.4.6. This is a bugfix release. All PHP 8.4 users are encouraged to upgrade to this version. For source downloads of PHP 8.4.6 please visit our downloads page. Windows binaries can be found on the PHP for Windows site. The list

Re: [PHP-DEV] [RFC] [Discussion] Change default for zend.exception_ignore_args INI setting

I can't find any information on why this setting was introduced. I guess that it was either to protect sensitive information or to reduce verbosity in the logs, but either one seems like a poor reason for this setting to exist. The INI comment seems to suggest that it was introduced to protect sens

  1   2   3   4   5   6   7   8   9   10   >