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] 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

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] 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] [RFC] [Discussion] array_first() and array_last()

On Sat, Apr 5, 2025 at 9:51 AM 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 I dislike all the functions where `null` is a valid value, which can also be confu

Re: [PHP-DEV] [VOTE] Optional Interfaces

On Fri, Mar 14, 2025 at 4:12 AM Juris Evertovskis wrote: > > Hello, > > > > I’ve opened the vote on the Optional interfaces RFC. > > > > https://wiki.php.net/rfc/optional-interfaces > > > > Implementation: https://github.com/php/php-src/pull/17288 > > Discussion: https://externals.io/message/12618

Re: [PHP-DEV] Make Closure covariant to callable

> > There are some weird cases with `callable` which is why they aren't > > allowed as a property type. I don't remember all the edges, but if we > > are sure that we cannot hit those with simple co-/contra-variance, > > then I don't think this needs an RFC and we can just merge the PR. > > The rea

Re: [PHP-DEV] Make Closure covariant to callable

There are some weird cases with `callable` which is why they aren't allowed as a property type. I don't remember all the edges, but if we are sure that we cannot hit those with simple co-/contra-variance, then I don't think this needs an RFC and we can just merge the PR.

Re: [PHP-DEV] Which IDE do you recommend for php-src development?

On Sat, Sep 14, 2024 at 3:47 PM Barel wrote: > > Hi > > For C/C++ development I usually use CLion from Jetbrains but I tried to use > it with php-src and was unable to get it to work properly. CLion really > insists on using CMake and has only quite limited support for makefiles. > After trying

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

On Tue, Aug 20, 2024 at 8:26 PM Christian Schneider wrote: > > Am 20.08.2024 um 17:14 schrieb Levi Morrison : > > Keep in mind that qualifying > > every global function is annoying but probably can be somewhat > > automated, and will bring better performance. So agai

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

> To sum up, I think we need to remove the fallback behavior, so we can have > better things in the future. > Either keep only local with a bigger BC break but a better language > consistency. > Or keep only global with a smaller BC break. I have long been in favor of a larger BC break with bett

Re: [PHP-DEV] String enums & __toString()

On Fri, Aug 16, 2024 at 1:43 PM John Coggeshall wrote: > > Hey all, > > I poked around a bit in the Enum RFCs and I could find (maybe I missed) > what's up with this: > > enum Foo:string implements \Stringable > { > case FOO = 'bar'; > > public function __toString() { > return $th

Re: [PHP-DEV] Require C11 in PHP 8.4

On Tue, Aug 13, 2024 at 8:17 AM Ilija Tovilo wrote: > > Hi Levi > > On Mon, Aug 12, 2024 at 5:56 PM Levi Morrison > wrote: > > > > Given the timetable, I wouldn't change the C std requirements for 8.4. > > Just to state it officially: You object to switchin

Re: [PHP-DEV] Require C11 in PHP 8.4

On Sat, Aug 10, 2024 at 6:22 AM Christoph M. Becker wrote: > > On 01.08.2024 at 23:57, Ilija Tovilo wrote: > > > Hence, it seems like it would be ok to bump our C compiler requirement > > to C11. We'd like to make this change before beta 1 if there are no > > objections. There are no immediate pla

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Sun, Aug 11, 2024 at 4:54 PM Lanre wrote: > > Hello, > > I’m considering adding some C++ enhancements to the Zend API. These changes > would be encapsulated within `#ifdef __cplusplus` guards, so they wouldn’t > interfere with the existing C implementation. The primary goal is to provide > a

Re: [PHP-DEV] Require C11 in PHP 8.4

On Sun, Aug 4, 2024 at 10:05 AM Gina P. Banyard wrote: > > > On Friday, 2 August 2024 at 14:33, Giovanni Giacobbi > wrote: > > On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo wrote: >> >> [...] >> I started fixing these in a PR [1] which required more changes than >> expected. After a short discourse

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function

On Tue, Jul 30, 2024 at 3:52 AM Gina P. Banyard wrote: > > Hello Internals, > > I have just opened the vote for the "Transform exit() from a language > construct into a standard function" RFC: > https://wiki.php.net/rfc/exit-as-function > > The vote will last for two weeks until the 13th of Augus

Re: [PHP-DEV] array_reduce callback key

On Tue, Jul 16, 2024 at 5:17 PM Bilge wrote: > > Hi Internals, > > I just ran into a case where I needed the array key in an array_reduce() > callback, but I can't access it :( > > So I wrote a PR to fix it: https://github.com/php/php-src/pull/14986 > > What do you think? Does this need an RFC? >

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

> Everything considered, I still do not think changing the name of the append() > method is a good idea, will it hurt adoption in the short term for some > classes, yes, but I prefer this than having a large part of the ecosystem > needing to create an alias just for some weird cases. I don't f

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

> Moreover, I know the traffic on the list has been pretty high, but I do > intend to have this RFC up for voting for inclusion in PHP 8.4, and I'm not > exactly sure how I am meant to interpret the lack of responses. I am personally strongly in favor of the direction. As mentioned in the PR, my

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

On Tue, Jul 9, 2024 at 10:18 AM Richard Miles wrote: > > Hi Levi, > > First, were you able to discuss this with authors of other generic > proposals or implementations? Derick Rethans and Arnaud Le Blanc both > have experience there. > > > This proposal has nothing to do with generics. > Derick Re

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

> 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 example is for properties

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] [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] Revisiting case-sensitivity in PHP

> Could you, please, elaborate on why you propose to target 9.0? That would > make perfect sense if PHP strictly followed semver, but we always have some > BC breaks in minor releases > (https://www.php.net/manual/en/migration82.incompatible.php, > https://www.php.net/manual/en/migration83.inco

Re: [PHP-DEV] Revisiting case-sensitivity in PHP

On Mon, Jun 10, 2024 at 9:40 PM Ben Ramsey wrote: > > > On Jun 10, 2024, at 20:35, Valentin Udaltsov > > wrote: > > > > Hi, internals! > > > > 9 years have passed since the last discussions of case sensitive PHP: > > https://externals.io/message/79824 and https://externals.io/message/83640. > >

Re: [PHP-DEV] RFC [Discussion]: array_find

On Tue, Apr 23, 2024 at 1:53 PM Joshua Rüsweg wrote: > > Hi > > On 19.04.24 21:20, Joshua Rüsweg wrote: > > I definitely see the point where there is an advantage to having two > > separate methods and can definitely understand that it is easier for > > developers to understand the control flow wi

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

On Tue, Apr 23, 2024 at 7:30 AM Benjamin Außenhofer wrote: > > Hi internals, > > My PR for #[\Deprecated] attribute was in hibernation for a long while now > and after some off-list discussion a few weeks ago I have decided to revisit > it and asked Tim to help me out with the work. > > Tim has

Re: [PHP-DEV] RFC [Discussion]: array_find

> On 07.04.24 16:35, Larry Garfield wrote: > > 1. Should this work on arrays or iterables? This is a long standing > > limitation of PHP. The array operations don't work on iterables, even > > though we've had iterables for 20 years.) > > In the longer term, it definitely makes sense to create

Re: [PHP-DEV] RFC [Discussion]: array_find

On Sun, Apr 7, 2024 at 8:38 AM Larry Garfield wrote: > > On Sun, Apr 7, 2024, at 10:20 AM, Joshua Rüsweg wrote: > > Hi > > I have created an RFC to add the function array_find which returns the > > first element for which a predicate callback returns true. This is a > > function which I missed oft

Re: [PHP-DEV] [RFC] [Discussion] new MyClass()->method() without parentheses

I haven't verified the implementation, but as long as there really aren't backwards compatibility issues for correct code, then this would be a nice quality of life improvement.

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

On Mon, Apr 8, 2024 at 3:42 PM Ilija Tovilo wrote: > > Hi everyone > > Heads-up: Larry and I would like to start the vote of the property > hooks RFC tomorrow: > https://wiki.php.net/rfc/property-hooks > > We have worked long and hard on this RFC, and hope that we have found > some middle-ground t

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

On Wed, Nov 15, 2023 at 2:26 PM Jorg Sowa wrote: > > Hello internals! > I have just opened voting on the RFC to add 4 new rounding modes to round() > function. > > Voting will end November 30th, 00:00 GMT. > > Link: > https://wiki.php.net/rfc/new_rounding_modes_to_round_function > > I'm sorry for

Re: [PHP-DEV] Two new functions array_first() and array_last()

> > This is simply not true, 0 is not always the first key in a list, > > especially after filtering it. Hence there is a need for this function > > in the first place. > > Just to clarify this point: If 0 is not the first key, then it's not a list. > After filtering a list, you get an array that m

Re: [PHP-DEV] Two new functions array_first() and array_last()

> c) Two such functions were proposed and rejected during the > array_key_first/last RFC > (https://wiki.php.net/rfc/array_key_first_last) > > Yes, that was in 2018. At that time, functions like str_contains() or > str_starts_with() wouldn't have even come into existence, just because > there was a

Re: [PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov wrote: > > Hi internals, > > The vote on "A new JIT implementation based on IR Framework" RFC is started. > > https://wiki.php.net/rfc/jit-ir > > Thanks. Dmitry. >From the RFC: > The details of the IR framework are complex. This [presentation][1] expl

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

> Please find the following resources for your references: > > RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023 > Discussion Thread: https://externals.io/message/121004 > Feedback by a Hashcat team member on Fediverse: > https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075 I d

Re: [PHP-DEV] [RFC][Draft] Match block

> 2. Support block expressions as a language-level concept, analogous to > https://doc.rust-lang.org/reference/expressions/block-expr.html This is my personal preference. As I mentioned in chat, if we go this route, there is a notable pain point: in "short" closures which have blocks, how do you c

Re: [PHP-DEV] [VOTE] Support optional suffix parameter in tempnam

On Sun, Aug 27, 2023 at 4:20 AM Tim Düsterhus wrote: > > Hi Athos > > On 8/27/23 04:02, Athos Ribeiro wrote: > > I am moving this RFC [1] to the voting phase. Voting will be open for the > > next 2 weeks, until September 10th, as per https://wiki.php.net/rfc. > > > > [1] https://wiki.php.net/rfc/

Re: [PHP-DEV] [VOTE] Interface Default Methods

On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks >

[PHP-DEV] Re: [VOTE] Interface Default Methods

On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks >

Re: [PHP-DEV] [VOTE] Interface Default Methods

On Mon, Jul 3, 2023 at 2:54 AM Tim Düsterhus wrote: > > Hi > > On 7/3/23 02:11, Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > > the past 6 days, and the feature freeze deadline is fast approaching > > for PHP 8.3, so

Re: [PHP-DEV] [VOTE] Interface Default Methods

On Sun, Jul 2, 2023 at 7:08 PM Ben Ramsey wrote: > > On Jul 2, 2023, at 19:11, Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving

[PHP-DEV] [VOTE] Interface Default Methods

Chatter on the [Interface Default Methods RFC][1] has been quiet for the past 6 days, and the feature freeze deadline is fast approaching for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks as usual. Thanks to everyone who discussed weaknesses in the RFC during the discussion phas

Re: [PHP-DEV] [RFC] [VOTE] Deprecate remains of string evaluated code assertions

On Wed, Jun 28, 2023 at 10:09 AM G. P. B. wrote: > > Hello internals, > > I'm opening the vote for the > Deprecate remains of string evaluated code assertions RFC: > https://wiki.php.net/rfc/assert-string-eval-cleanup > > It will last for two weeks and end on Wednesday the 12th of July > > Best re

Re: [PHP-DEV] [RFC] Interface Default Methods

On Tue, Jun 20, 2023 at 9:46 PM Levi Morrison wrote: > > On Tue, Jun 20, 2023 at 6:29 AM David Gebler wrote: > > > > On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote: > > > > > > I like the idea of this RFC - in fact it's one which has been near to

Re: [PHP-DEV] [RFC] Interface Default Methods

On Tue, Jun 20, 2023 at 6:29 AM David Gebler wrote: > > On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote: > > > > I like the idea of this RFC - in fact it's one which has been near top of > > > my wishlist for PHP language features for a long time - but I think thi

Re: [PHP-DEV] [RFC] Interface Default Methods

On Sat, Jun 17, 2023 at 6:05 AM Alexandru Pătrănescu wrote: > > Thank you for this! > I like the proposal and I think it fits well. > I'm used to it from Java and I don't know any reason for it to be > considered a bad practice since it was introduce, about 9-10 years ago. > > 1. Do we want to all

Re: [PHP-DEV] [RFC] Interface Default Methods

> I like the idea of this RFC - in fact it's one which has been near top of > my wishlist for PHP language features for a long time - but I think this is > an issue with the proposed implementation which at the very least warrants > highlighting and discussion. I understand your concern but person

Re: [PHP-DEV] [RFC] Interface Default Methods

On Sat, Jun 17, 2023 at 4:10 PM David Gebler wrote: > > On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals > wrote: >> >> >> I am moving my RFC for interface default methods to discussion: >> https://wiki.php.net/rfc/interface-default-methods. >

Re: [PHP-DEV] [RFC] Interface Default Methods

On Thu, Jun 15, 2023 at 5:41 PM Levi Morrison via internals wrote: > > On Thu, Jun 15, 2023 at 3:37 PM Ilija Tovilo wrote: > > > I am moving my RFC for interface default methods to discussion: > > > https://wiki.php.net/rfc/interface-default-methods. > > >

Re: [PHP-DEV] [RFC] Interface Default Methods

On Fri, Jun 16, 2023 at 11:51 AM Deleu wrote: > > > On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals > wrote: >> >> Hello, PHP Internals, >> >> I am moving my RFC for interface default methods to discussion: >> https://wiki.php.net/rfc/inte

Re: [PHP-DEV] [RFC] Interface Default Methods

On Thu, Jun 15, 2023 at 3:37 PM Ilija Tovilo wrote: > > I am moving my RFC for interface default methods to discussion: > > https://wiki.php.net/rfc/interface-default-methods. > > The RFC doesn't mention default implementations for static methods. > I'm not sure there's a use case but it might mak

Re: [PHP-DEV] [RFC] Interface Default Methods

On Thu, Jun 15, 2023 at 9:16 AM Tim Düsterhus wrote: > > Hi > > On 6/15/23 17:08, Deleu wrote: > > The feature may introduce a new way for *Users of PHP* to break BC with > > *Other Users of PHP*. The language change itself has no impact on PHP code > > written prior to the feature. The additional

Re: [PHP-DEV] [RFC] Interface Default Methods

> I still believe this information should be added to the RFC as the risk > of adding new methods to an interface which collide with existing > methods in implementations of that interface is very real, though I > agree with Deleu that this BC impact is not so much of the RFC, but of > what can hap

[PHP-DEV] [RFC] Interface Default Methods

't implemented. Thank you for your time. I look forward to productive feedback. Levi Morrison -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Wed, Jun 14, 2023 at 4:06 AM Derick Rethans wrote: > > On Tue, 13 Jun 2023, Nicolas Grekas wrote: > > > > I'm going to nitpick on the newly suggested names and argument order for > > > the > > > DatePeriod factory methods — althoughI do agree that they need to get > > > created: > > > > > > cre

Re: [PHP-DEV] [RFC] [Discussion] Clone with

On Mon, Apr 17, 2023 at 12:32 AM Máté Kocsis wrote: > > Hi Everyone, > > Quite some time after mentioning the "clone with" construct the first time > (at the end of the > https://wiki.php.net/rfc/write_once_properties#run-time_behaviour section), > finally I managed to create a working implementat

Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`

On Tue, May 30, 2023 at 5:35 AM Boro Sitnikovski wrote: > > Hello all, > > As per the How To Create an RFC instructions, I am sending this e-mail in > order to get your feedback on my proposal. > > I propose introducing a function to PHP core named `array_group`. This > function takes an array a

Re: [PHP-DEV] Final anonymous classes

I am not sure about making them final by default. I think it's a more consistent language design to allow `new final class()` as you originally proposed. Although I don't know why anyone would want to extend anonymous classes, we can see that people do, in fact, do it. I don't see why we couldn't a

Re: [PHP-DEV] [VOTE] PHP Technical Committee

On Fri, Apr 28, 2023 at 4:01 AM Jakub Zelenka wrote: > > Hi, > > The vote is now open for the RFC about introduction of the PHP Technical > Committee: > > https://wiki.php.net/rfc/php_technical_committee > > Regards > > Jakub Do we really need this level of bureaucracy? I mean... I know someone's

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

On Thu, Apr 20, 2023 at 9:57 PM Deleu wrote: > > > > On Thu, Apr 20, 2023 at 8:23 PM Levi Morrison via internals > wrote: >> >> I'm going to stop here. Two big things: >> >> 1. I think reducing verbosity can be left for the future. We don'

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

On Thu, Apr 20, 2023 at 11:25 AM Larry Garfield wrote: > > Hi folks. This is a pre-discussion, in a sense, before a formal RFC. > Nicolas Grekas and I have been kicking around some ideas for how to address > the desire for typed callables, and have several overlapping concepts to > consider.

Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments

On Fri, Jan 27, 2023 at 8:54 AM Larry Garfield wrote: > > On Fri, Jan 27, 2023, at 3:00 AM, Andreas Heigl wrote: > > Hey Folks. > > > > I think it would be a good idea to deprecate calling ldap_connect with 2 > > parameters host and port. > > > > Wait: What? > > > > Currently there are three ways

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

It seems to me that if you truly want to clean up this specific part of the language, you are going to have to play the long game: 1. New functions are added for the perl behavior of string increment and decrement. No warnings are given in code, but call-outs are made in upgrading and other docume

Re: [PHP-DEV] RFC: rules for #include directives

As commented yesterday on one of the PRs, I strongly agree with the cleanups. Our code has implicit dependencies and if you reorder the includes in the same file, you can break builds. That shouldn't ever happen. I also agree that dtrace breaking is a failure of CI and testing, not necessarily the

Re: [PHP-DEV] ARRAY_UNIQUE_IDENTICAL option

A bit off topic, but not entirely: In my opinion, adding another flag isn't the _real_ fix. Any function which does comparisons should take a callable for users to provide any comparison they wish. An iteratively better API would be: function array_unique(list $array, callable(T $a, T $b): in

Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2

FYI, it is also noted in the [UPGRADING][1] file: > - Core: > . The iterable type is now a built-in compile time alias for > array|Traversable. >Error messages relating to iterable will therefore now use > array|Traversable. >Type Reflection is preserved for single iterable (and ?iterab

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

> > There's other functionality that I was less certain about proposing, such > > as `iterable\keys(iterable $iterable): array`, > > which would work similarly to array_keys but also work on Traversables > > (e.g. to be used with userland/internal collections, generators, etc.) > > I assume this

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

> Namespaces were chosen after feedback on my previous RFC, > and I believe `iterable\` follows the guidance from > https://wiki.php.net/rfc/namespaces_in_bundled_extensions and > https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl I support this general direction :thumbsu

Re: [PHP-DEV] Proposal to incrementally improve timeout and signal handling

This kind of thing requires careful thought. My first glance through it looks good and I definitely want PHP to stop abusing the SIGPROF signal because it prevents usage by actual profilers, which is annoying. Full disclosure: I write a profiler for my job. In addition, I think that there should p

Re: [PHP-DEV] Newcomer, PHP pre-processing, Magic Constants __FILE__ and __LINE__ override with #line like in C

> I think you're also greatly over-estimating how large the startup cost is in > practice. It's real, certainly, but unless you have several nested > microservices a well-made framework should have a fairly small overhead. I want to share my experience that some users have very slow file I/O, a

Re: [PHP-DEV] [Concept] Extension methods

> What are your thoughts? It's a fantastic feature that I've used in Rust, although there are some differences. First, it doesn't work for regular methods -- they have to be part of a trait. Secondly, in general a trait can only be implemented for a given type if it is in the package which defines

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

On Tue, Jul 5, 2022 at 3:39 PM shinji igarashi wrote: > > Hello internals, > > I've started the vote for the Constants in Traits RFC: > https://wiki.php.net/rfc/constants_in_traits > > The vote will end on 19. July 2022. > > Thanks! > > -- > Shinji Igarashi > > -- > PHP Internals - PHP Runtime Dev

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron wrote: > > Hi all, > > > > - The new CurlUrl class should probably be immutable from the start. It > > was my biggest mistake not to do that with DateTime. > > > > > After thinking about it and some discussions, I followed Derick's > recommendation

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron wrote: > > Hi, > > Following our discussions we had on the subject of the new Curl URL API, > and other curl improvements. I decided to only focus on adding the new Curl > URL API and put aside all other improvements. Here is the RFC that reflects

Re: [PHP-DEV] Make iterator_to_array() accept all iterables

On Fri, Jun 17, 2022 at 9:28 AM G. P. B. wrote: > > On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus wrote: > > > Hi Internals > > > > I've come across a case where it would've been useful if > > `iterator_to_array()` would accept iterable instead of Traversable to > > avoid checking whether the input

[PHP-DEV] Questions on history of zend_module_entry

Hello, for two separate reasons I was recently reviewing zend_module_entry's layout and usage and there are two things I don't understand: 1. Why does zend_module_entry have a `.size` member, if it's not actually used anywhere as far as I can tell from both reading code and setting debugger watch

Re: [PHP-DEV] [RFC] Disjunctive Normal Form Types

> DNF types are a way to mix intersection and union types together in a > single type. > For example: > [...] > - (Traversable&Countable)|array I have yet to read the fine print, but this example was a motivating case for me to start down the union-types road years ago. I would be very happy to

Re: [PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

On Sat, Mar 12, 2022 at 10:32 AM G. P. B. wrote: > > I've started voting for the Allow null and false as stand-alone types RFC: > https://wiki.php.net/rfc/null-false-standalone-types > > Voting will last for 2 weeks until 26th of March. > > Best regards, > > George P. Banyard Hello, I have voted

Re: [PHP-DEV] Adding `final class Deque` to PHP

I think this RFC is in much better shape now. The last thing I'll personally push for is dropping `get` and `set`. I'm not sure about those names, and the functionality is already provided by `offsetGet` and `offsetSet`, albeit through `mixed` instead of `int`, but I think this sort of cleanup sho

Re: [PHP-DEV] [Help] Reason on when to declare and protect ZEND_API function

On Thu, Jan 20, 2022 at 1:56 AM Su, Tao wrote: > > Hello internals, > > I am trying to read Zend header files to understand its functional interfaces, > but have got confusion and anybody knows why zend_startup_system_id() and > zend_finalize_system_id() > do not have to be protected by BEGIN_EXT

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

On Tue, Dec 21, 2021 at 1:48 AM Hassan Ahmed <7sno...@gmail.com> wrote: > > Hello all, > > I would like to start a voting phase for this RFC: Add array_group function > > > Regards, > > ~Hassan This RFC has mistakes in its opening Discussion

Re: [PHP-DEV] Re: PHP-FPM process management woes

As Jakub mentioned, exactly one MINIT/MSHUTDOWN per process will only fix one of your problems, but I do like the step in that direction. I express my sympathy and condolences: I've had my own share of woes with the fact that env var and INI changes are not complete during MINIT due to fcgi protoc

Re: [PHP-DEV] Surveying interest regarding CMake

On Fri, Dec 17, 2021 at 6:49 AM Horváth V. wrote: > > One thing I forgot to ask is what minimum CMake version should php-src > support in its build scripts? For reference, please take a look at > repology.org for the packaging status of CMake across a lot of software > distributions: https://repol

Re: [PHP-DEV] Surveying interest regarding CMake

On Thu, Dec 16, 2021 at 1:13 PM Horváth V. wrote: > > > My main question would be how this will affect 3rd party extensions, > > which are currently using autoconf. Will they need to migrate to > > cmake, or will we have to effectively maintain both build systems? > > Unless 3rd party extensions v

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

> if hosting it ourself is a priority, i suggest looking into GitLab’s > Community Edition, which is entirely open source, > and the GNOME project moved from Bugzilla to GitLab CE in 2018, > here's how that worked out, 2 years later: > https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/ > (an

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

> Based on the received feedback, I've updated the RFC to instead provide an > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > dynamic properties. As previously discussed, this won't allow us to > completely remove dynamic properties from the language model anymore, but > it

Re: [PHP-DEV] [Pre-Vote Announcement] Move RNG functions Random Extension

On Mon, Oct 4, 2021 at 4:21 AM Nikita Popov wrote: > > On Wed, Sep 22, 2021 at 1:21 PM Go Kudo wrote: >> >> The voting phase for the following RFCs will begin as soon as two weeks >> have passed. >> >> https://externals.io/message/115975 >> >> I don't see any particular discussion, so I'm contact

Re: [PHP-DEV] [RFC] Allow null as standalone type

On Tue, Oct 5, 2021 at 8:08 AM Côme Chilliet wrote: > > Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a écrit : > > If we make this change, I would however suggest to also support "false" as > > a standalone type. I think this change primarily has benefits from a > > typesystem completeness

Re: [PHP-DEV] [RFC] Allow null as standalone type

On Sat, Oct 2, 2021 at 9:07 AM G. P. B. wrote: > > Hello internals, > > I'm proposing a new RFC to make 'null' usable as a standalone type. > > RFC: https://wiki.php.net/rfc/null-standalone-type > GitHub PR: https://github.com/php/php-src/pull/7546 > > Best regards, > > George P. Banyard I don't

Re: [PHP-DEV] Static (factory) methods in attributes and initializers

I'm not exactly sure what you are proposing. However, it's always worth noting other languages which have something in the feature space, and Dart has both named constructors and factory constructors. You should start with researching what they do, and what other languages may have the same as _lan

Re: [PHP-DEV] BC breaking changes in PHP 8.1

> As somebody who's been contributing to and maintaining OSS libraries > forever (since 2002), the pace of change of PHP is, frankly, ridiculous. I > can keep up with patches. I can keep up with new features. But BC breaks > EVERY YEAR just creates churn. I've spent most of the past 18 months doing

Re: [PHP-DEV] Adding `final class Deque` to PHP

> "Maximum size" shouldn't be an issue for `Deque` specifically, it's a > `size_t`. It isn't an issue for SplFixedArray and ArrayObject. > (or for > PHP would just encounter a fatal error due to either You wrote a lot, but unfortunately it was based on a misunderstanding. In some languages you ca

Re: [PHP-DEV] Adding `final class Deque` to PHP

The name "deque" is used in the standard library of these languages: - C++: std::deque - Java: java.util.Deque (interface) - Python: collections.deque - Swift: Collections.Deque (not standard lib, apparently, but Apple official? Don't know Swift) - Rust: std::collections::VecDeque And these

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> * Whether or not contains() needs a comparison callback in my mind depends > mainly on whether or not the operator overloading RFC passes. If it does, > then contains() can/should use the __compareTo() method on objects. If it > doesn't, then there needs to be some other way to compare non-i

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> I'd considered using a signature of `setSize(int $size, mixed $value = null)` > to allow using something other than null > but decided to leave that to a followup proposal if it passed. Rust and C++ both accept a value to pad, there's no reason to restrict this to only null. Go ahead and make t

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> > - `contains` also doesn't have a comparator. > > I was considering proposing `->any(callable)` and `->all(callable)` > extensions if this passed. > I'm not quite sure what you mean by a comparator for contains. There'd have > to be a way to check if a raw closure is contained. I mean that th

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

On Thu, Sep 16, 2021 at 8:10 PM tyson andre wrote: > > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add > `final class Vector` to PHP. > > PHP's native `array` type is rare among programming language in that it is > used as an associative map of values, b

Re: [PHP-DEV] Alias stdClass to DynamicObject?

On Mon, Sep 6, 2021 at 9:29 AM Nikita Popov wrote: > > Hi internals, > > In the thread for deprecation of dynamic properties, Rowan suggested that > we alias "stdClass" to "DynamicObject" in > https://externals.io/message/115800#115802. I wanted to split this > discussion off into a separate threa

  1   2   3   4   5   6   7   8   9   10   >