Following recent discussions regarding performance benchmarking methodology
for the array_str_contains proposal, the benchmark tests have been removed
to better align with the feedback received on the project's testing scope
and requirements.
Hi
Following recent discussions regarding performance benchmarking
methodology
for the array_str_contains proposal, the benchmark tests have been
removed
to better align with the feedback received on the project's testing
scope
and requirements.
Can you please keep all the discussion and updates related to your RFC
within the same official discussion thread? Creating new threads for
everything makes it much harder for users to find what opinions and
changes went into the RFC, since there is no link between them.
Best regards
Tim Düsterhus
در تاریخ دوشنبه ۱۴ سپتامبر ۲۰۲۶، ۱۰:۱۲ Tim Düsterhus tim@bastelstu.be
نوشت:
Hi
Following recent discussions regarding performance benchmarking
methodology
for the array_str_contains proposal, the benchmark tests have been
removed
to better align with the feedback received on the project's testing
scope
and requirements.Can you please keep all the discussion and updates related to your RFC
within the same official discussion thread? Creating new threads for
everything makes it much harder for users to find what opinions and
changes went into the RFC, since there is no link between them.Best regards
Tim Düsterhus
Hi everyone,
Due to some technical issues, the previous email thread is no longer
accessible. To follow the recommendation of keeping all discussions in a
single, official thread, we will be continuing the conversation regarding
the array_str_contains() RFC here.
Looking forward to your feedback and continuing the discussion in this
thread.
Best regards,
Sepehr
Hi internals,
It has been 3 days now and no one has agreed on running the benchmark
tests for my function.If there is no agreement on keeping the benchmarks within the next 2 days,
the benchmarks will be completely canceled for my function.I look forward to hearing your valuable feedback. Also, this thread is not
just for the benchmarks of this function; you can share any valuable
feedback or thoughts you have regarding my function in this thread.With respect,
Sepehr
Hi internals,
It has been 3 days now and no one has agreed on running the benchmark tests for my function.
If there is no agreement on keeping the benchmarks within the next 2 days, the benchmarks will be completely canceled for my function.
I look forward to hearing your valuable feedback. Also, this thread is not just for the benchmarks of this function; you can share any valuable feedback or thoughts you have regarding my function in this thread.
With respect,
Sepehr
I'm pretty sure the reason no one has looked at your benchmarks is no one supports this function. I don't believe I've seen a single person agree with you that it's useful. You have just been flooding the list with messages assuming this function will be the greatest thing since sliced bread, across multiple threads for no apparent reason. You've already been advised, both on list and off, on an alternate approach for your specific use case. It seems obvious to me that PHP-Internals is just not interested in this functionality. Period.
Whether you're using AI or not, your posts are not helpful or constructive and people are tired.
It's OK to have a proposal rejected. Even very experienced long time contributors have ideas declined early on. It is part of the process, and that's OK. Pushing and pushing and pushing after it's clear that it's not going to happen is not a part of the process. It's just a waste of everyone's time.
Please stop wasting everyone's time.
--Larry Garfield
در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield <
larry@garfieldtech.com> نوشت:
Hi internals,
It has been 3 days now and no one has agreed on running the benchmark
tests for my function.If there is no agreement on keeping the benchmarks within the next 2
days, the benchmarks will be completely canceled for my function.I look forward to hearing your valuable feedback. Also, this thread is
not just for the benchmarks of this function; you can share any valuable
feedback or thoughts you have regarding my function in this thread.With respect,
SepehrI'm pretty sure the reason no one has looked at your benchmarks is no one
supports this function. I don't believe I've seen a single person agree
with you that it's useful. You have just been flooding the list with
messages assuming this function will be the greatest thing since sliced
bread, across multiple threads for no apparent reason. You've already been
advised, both on list and off, on an alternate approach for your specific
use case. It seems obvious to me that PHP-Internals is just not interested
in this functionality. Period.Whether you're using AI or not, your posts are not helpful or constructive
and people are tired.It's OK to have a proposal rejected. Even very experienced long time
contributors have ideas declined early on. It is part of the process, and
that's OK. Pushing and pushing and pushing after it's clear that it's not
going to happen is not a part of the process. It's just a waste of
everyone's time.Please stop wasting everyone's time.
--Larry Garfield
Hi Larry,
I need to clarify a few points regarding your email. First, you initially
set providing benchmarks as a primary condition for this RFC. Later, in
private, you told me they weren't necessary. Now, claiming that these
benchmarks are invalid or non-existent completely contradicts your own
initial request.
As for performance, I’ve already conducted a real-world usage analysis, and
the JSON results are documented in the RFC. They clearly show that this
function outperforms the alternatives you suggested.
Given the documentation and the results, I cannot accept your assessment
that the benchmarks are invalid. The performance of this function is proven.
Regards,
Sepehr
در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield
larry@garfieldtech.com نوشت:Hi internals,
It has been 3 days now and no one has agreed on running the benchmark tests for my function.
If there is no agreement on keeping the benchmarks within the next 2 days, the benchmarks will be completely canceled for my function.
I look forward to hearing your valuable feedback. Also, this thread is not just for the benchmarks of this function; you can share any valuable feedback or thoughts you have regarding my function in this thread.
With respect,
SepehrI'm pretty sure the reason no one has looked at your benchmarks is no one supports this function. I don't believe I've seen a single person agree with you that it's useful. You have just been flooding the list with messages assuming this function will be the greatest thing since sliced bread, across multiple threads for no apparent reason. You've already been advised, both on list and off, on an alternate approach for your specific use case. It seems obvious to me that PHP-Internals is just not interested in this functionality. Period.
Whether you're using AI or not, your posts are not helpful or constructive and people are tired.
It's OK to have a proposal rejected. Even very experienced long time contributors have ideas declined early on. It is part of the process, and that's OK. Pushing and pushing and pushing after it's clear that it's not going to happen is not a part of the process. It's just a waste of everyone's time.
Please stop wasting everyone's time.
--Larry Garfield
Hi Larry,
I need to clarify a few points regarding your email. First, you
initially set providing benchmarks as a primary condition for this RFC.
Later, in private, you told me they weren't necessary. Now, claiming
that these benchmarks are invalid or non-existent completely
contradicts your own initial request.
This is an outright lie.
I previously stated that if your argument for a feature is performance, then it needs benchmarks to demonstrate that performance.
Weeks later (a few days ago), you emailed me directly asking for help with CI issues on your PR.
This was my response:
Hi Sepehr.
I... don't know why you're asking me for help on this. I am very open that while I do a lot of design work for PHP, actually working on the codebase is not something I'm good at. I barely manage to read a few parts of it, and don't know the first thing about why FreeBSD builds or such would die.
This would be a question better directed at the list, or just ask for help on the PR itself.
That said, I am also not sure why you're still pushing for that function. The feedback has been universally negative. I'd lay good money that the RFC never passes, no matter what your benchmarks say. As I said weeks ago, if your particular code base is such that this is your bottleneck, then first congrats on having a very efficient application, and second, it's time to write a tiny extension for just your project.
This is not saying "benchmarks aren't necessary," "benchmarks are invalid," or "non-existent." It's saying "stop wasting your time and everyone else's, no one wants your RFC." That is still what I am saying. (And looking at the RFC on the wiki, I don't actually see benchmarks listed.)
As for performance, I’ve already conducted a real-world usage analysis,
and the JSON results are documented in the RFC. They clearly show that
this function outperforms the alternatives you suggested.
The alternative I suggested, weeks ago and in the email above, is writing your own tiny extension to provide the C function you have already written. Its performance, whatever it is, should be identical regardless of whether it's in stdlib or your own extension. Your response here is completely inaccurate and grossly misrepresents my very clear statements on the matter.
Given the documentation and the results, I cannot accept your
assessment that the benchmarks are invalid. The performance of this
function is proven.
Once again:
- I never said they are invalid.
- There are no benchmarks on the RFC listed on the RFC index page (although the formatting is broken)
- What I said is that no one is interested in this proposal, regardless of its performance, so please stop wasting our time and yours.
If you are unable to engage honestly and without misrepresenting what others have said on this topic, then please remove yourself from the mailing list.
--Larry Garfield
در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۱۶:۴۱ Larry Garfield <
larry@garfieldtech.com> نوشت:
در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield
larry@garfieldtech.com نوشت:Hi internals,
It has been 3 days now and no one has agreed on running the
benchmark tests for my function.If there is no agreement on keeping the benchmarks within the next 2
days, the benchmarks will be completely canceled for my function.I look forward to hearing your valuable feedback. Also, this thread
is not just for the benchmarks of this function; you can share any valuable
feedback or thoughts you have regarding my function in this thread.With respect,
SepehrI'm pretty sure the reason no one has looked at your benchmarks is no
one supports this function. I don't believe I've seen a single person
agree with you that it's useful. You have just been flooding the list with
messages assuming this function will be the greatest thing since sliced
bread, across multiple threads for no apparent reason. You've already been
advised, both on list and off, on an alternate approach for your specific
use case. It seems obvious to me that PHP-Internals is just not interested
in this functionality. Period.Whether you're using AI or not, your posts are not helpful or
constructive and people are tired.It's OK to have a proposal rejected. Even very experienced long time
contributors have ideas declined early on. It is part of the process, and
that's OK. Pushing and pushing and pushing after it's clear that it's not
going to happen is not a part of the process. It's just a waste of
everyone's time.Please stop wasting everyone's time.
--Larry Garfield
Hi Larry,
I need to clarify a few points regarding your email. First, you
initially set providing benchmarks as a primary condition for this RFC.
Later, in private, you told me they weren't necessary. Now, claiming
that these benchmarks are invalid or non-existent completely
contradicts your own initial request.This is an outright lie.
I previously stated that if your argument for a feature is performance,
then it needs benchmarks to demonstrate that performance.Weeks later (a few days ago), you emailed me directly asking for help with
CI issues on your PR.This was my response:
Hi Sepehr.
I... don't know why you're asking me for help on this. I am very open
that while I do a lot of design work for PHP, actually working on the
codebase is not something I'm good at. I barely manage to read a few parts
of it, and don't know the first thing about why FreeBSD builds or such
would die.This would be a question better directed at the list, or just ask for help
on the PR itself.That said, I am also not sure why you're still pushing for that function.
The feedback has been universally negative. I'd lay good money that the
RFC never passes, no matter what your benchmarks say. As I said weeks ago,
if your particular code base is such that this is your bottleneck, then
first congrats on having a very efficient application, and second, it's
time to write a tiny extension for just your project.This is not saying "benchmarks aren't necessary," "benchmarks are
invalid," or "non-existent." It's saying "stop wasting your time and
everyone else's, no one wants your RFC." That is still what I am saying.
(And looking at the RFC on the wiki, I don't actually see benchmarks
listed.)As for performance, I’ve already conducted a real-world usage analysis,
and the JSON results are documented in the RFC. They clearly show that
this function outperforms the alternatives you suggested.The alternative I suggested, weeks ago and in the email above, is writing
your own tiny extension to provide the C function you have already
written. Its performance, whatever it is, should be identical regardless
of whether it's in stdlib or your own extension. Your response here is
completely inaccurate and grossly misrepresents my very clear statements on
the matter.Given the documentation and the results, I cannot accept your
assessment that the benchmarks are invalid. The performance of this
function is proven.Once again:
- I never said they are invalid.
- There are no benchmarks on the RFC listed on the RFC index page
(although the formatting is broken)- What I said is that no one is interested in this proposal, regardless
of its performance, so please stop wasting our time and yours.If you are unable to engage honestly and without misrepresenting what
others have said on this topic, then please remove yourself from the
mailing list.--Larry Garfield
Hi Larry,
First, I have to point out that you told me to ignore benchmarks because
this function had no place in the core, yet now you claim it was a
misunderstanding.
Second, my RFC page has received a significant number of views, which again
contradicts your point.
Third, please stop trying to use language that leads the conversation in
the wrong direction.
Everyone is reading this email, and I have one question:
Does anyone here actually dislike my contributions to php-src????
With great respect to everyone and Mr. Garfield,
Mahmoudi
Second, my RFC page has received a significant number of views,
How can you tell? Considering the wiki software doesn't record view counts.
cheers
Derick
On Wed, 16 Sept 2026 at 15:19, سپهر محمودی sepehrphpr@gmail.com wrote:
Does anyone here actually dislike my contributions to php-src????
Yes.
Hi Sepehr
I sent personal mail.
Please check it.
Regards
Yuya
--
Yuya Hamada (tekimen)
On Wed, 16 Sept 2026 at 15:19, سپهر محمودی sepehrphpr@gmail.com
wrote:Does anyone here actually dislike my contributions to php-src????
Yes.
Yes from me as well. I don't know why you are persisting with this RFC. I
don't remember ever seeing so much mail in the list for such an unwanted
RFC.
I could understand if during the discussion stage, you got feedback like:
"OMG, I soooo need this." or "Finally! This has always been sorely missing
from the language." but that didn't happen. I hope you are not motivated to
contribute just so you can be considered a contributor. I hope ego or
prestige is not behind the unrelenting push.
Even if you can build a faster version in C, that doesn't mean it should be
added to the array_ functions family. I am sure dozens of callback
hybridized iterator functions could be written faster in C, but that is not
a green light to flood the core with more native functions.
As I mentioned previously, please silently compile your own list of
proposals. Once you have ~5 separate deeply-considered proposals that you
are proud of, then self-assess which is best and if it is worthy of
sharing. I have personally considered proposing array_transpose(),
preg_escape(), a PREG_ flag that omits unwanted full string matches,
making the third parameter of substr_replace() null by default to allow
suffixing an array of strings, and adopting .. range syntax across all
native functions which accept a character mask, but none of my arguments
feel like they would garner support. So, I'm keeping them locked away in my
mental vault. Maybe I'll have an epiphany that will make them attractive or
maybe they'll shape my thoughts on another idea. Not all ideas are winners,
that doesn't make someone a loser. Just keeping learning and growing.
Sincerely,
mickmackusa
Hi everyone,
I’m writing this because I feel it’s important to address the recent
friction. First and foremost, I want to sincerely apologize to the whole
internals community, and specifically to Larry Garfield.
As an aspiring contributor from Iran, I didn't fully understand the
community norms, etiquette, and the weight of the processes here, which led
to some misunderstandings and behavior that I now realize was
inappropriate. I deeply regret any disruption I’ve caused to your valuable
time and workflow.
I genuinely care about PHP and the work you all do. I hope you can accept
my apology. I promise to step back, reflect, and learn from this. I want to
show that I am capable of being a respectful and constructive member of
this community.
Thank you for your patience and for hearing me out. I would appreciate it
if you could share your valuable feedback and advice on how I can improve
and move forward.
Best regards,
Sepehr
Hi everyone,
Following the recent discussions, I have decided to withdraw the
array_str_contains RFC. I will be closing the corresponding PR shortly.
I would like to thank those who provided constructive feedback. I intend to
take some time to refine my approach and hope to contribute more useful
features and cleaner implementations to the project in the future.
Best regards,
Sepehr
I have noticed that my previous emails haven't received a response, and I
want to address this openly with everyone here.
I sincerely apologize for my recent behavior. As the first contributor from
Iran, reaching this point felt like overcoming impossible odds. Achieving
this level here is incredibly difficult—between the challenging educational
landscape, the lack of standard paths or certifications for PHP, and the
limited access to hands-on professional environments, getting to contribute
to the core is like climbing a mountain ten times over.
Because of this intense pressure, I lost my perspective. It was not my
intention to be difficult or aggressive. I ask you to please look at me
again as the Sepehr who first joined this community—eager and ready to
learn. I was wrong, and I am truly sorry.
Best regards,
Sepehr
I have noticed that my previous emails haven't received a response, and
I want to address this openly with everyone here.
Hey,
It's perfectly fine to not receive a response when you withdraw
an RFC, issue a correction or apologize. Don't worry about it!
A withdrawn RFC is withdrawn, there's nothing more to discuss.
Each mail sent on the list causes an avalanche of messages.
They get delivered to dozens, maybe hundreds of recipients.
It would be a mess if people were responding you with "ok, understood",
the lack of response is just a sane and pragmatic default --
it means no one has any substantial remark to add.
I'm only sending this so everyone knows this has been clarified.
No need to respond to this unless there's something new to bring up.
Let's keep unnecessary traffic to minimum.
BR,
Juris
P.S. Good luck with your further work on intl. I'm pretty sure most
people here will fairly evaluate that work itself, without worrying what
has
happened previously with other RFCs. Just forget about the drama and
keep the lessons ;)