Hello, folks. As discussed in previous messages [1], I am proposing
the creation of an alias function split to the explode function.
Here is the RFC for discussion:
https://wiki.php.net/rfc/create-split-alias-to-explode
Hello, folks. As discussed in previous messages [1], I am proposing
the creation of an alias functionsplitto theexplodefunction.Here is the RFC for discussion:
https://wiki.php.net/rfc/create-split-alias-to-explode
-1. My 2c is that aliases should be deprecated and eventually removed,
not more added. Modern PHP projects tend to have coding standards that
prohibit the use of aliases. See no_alias_functions PHP CS Fixer rule
for example. The existence of aliases only creates unnecessary noise
across the ecosystem, eg CI failing when someone does end up using the
alias. If you think that a function should be named this or that, you
can always create aliases in userland code.
Hi
Am 2025-08-18 16:57, schrieb Vinicius Dias:
Hello, folks. As discussed in previous messages [1], I am proposing
the creation of an alias functionsplitto theexplodefunction.Here is the RFC for discussion:
https://wiki.php.net/rfc/create-split-alias-to-explode
I feel like the current RFC text is very biased in favor of adding the
alias. I believe it would be prudent to also list possible caveats and
arguments against so that voters are able to make an educated decision.
Several points have already been raised in the pre-RFC discussion
thread, for example the possible confusion with str_split().
While it's not strictly necessary to follow the RFC template, it is
often a good idea to make sure everything is accounted for. The template
specifically contains an RFC impact section that is missing from your
RFC: https://wiki.php.net/rfc/template#rfc_impact.
The “Backwards Incompatible Changes” section should also mention that
split() would no longer be available to userland. Quoting from the
template:
Please include all breaking changes, no matter how minor they might
appear. All research you did on potential impact should be listed in
this section.
and
For adding new functions, classes or keywords, here are some
possibilities to measure potential impact:
(highlighting mine)
Best regards
Tim Düsterhus
I feel like the current RFC text is very biased in favor of adding the
alias. I believe it would be prudent to also list possible caveats and
arguments against so that voters are able to make an educated decision.
Fair point. I added that.
The “Backwards Incompatible Changes” section should also mention that
split()would no longer be available to userland.
I didn't realize not having the function available anymore could be a
breaking change. Good point. Added.
The template specifically contains an RFC impact section that is missing from your RFC:
I added that and the RFC Impact sections. I added "None" to the
existing extensions and SAPIs. Let me know if that should be like that
or if I should just omit those sections.
Let me know if that's enough or if I'm still missing something.
Thank you for the thorough feedback.
Hi
Apologies for the late response. I've now taken another look.
Am 2025-08-19 16:50, schrieb Vinicius Dias:
The template specifically contains an RFC impact section that is
missing from your RFC:I added that and the RFC Impact sections. I added "None" to the
existing extensions and SAPIs. Let me know if that should be like that
or if I should just omit those sections.
Having the sections with an explicit “None” makes sense to me.
Let me know if that's enough or if I'm still missing something.
Thank you for the thorough feedback.
While I still don't agree with the RFC, I believe it now fairly
represents the discussion and I don't think anything important is
missing from the RFC.
I'm just taking a bit of an issue with the “Dislike for aliases”
section: Just because folks (me included) are against adding more
aliases, does not imply that they are in favor of removing existing
aliases. I consider both adding new aliases as well as removing aliases
to be disruptive and believe that the best action is “doing nothing” and
accepting this as another case of a historical decision that might not
have been made today.
Best regards
Tim Düsterhus
I believe it now fairly represents the discussion and I don't think anything important is missing from the RFC.
Perfect, thank you.
I plan to open it for voting next Monday (Sep 1st) since it will be 2
weeks since this discussion started.
Since there is over 2 weeks of open discussion about this RFC[1], I
plan to open it for voting tomorrow.
Hello, folks. As discussed in previous messages [1], I am proposing
the creation of an alias functionsplitto theexplodefunction.Here is the RFC for discussion:
https://wiki.php.net/rfc/create-split-alias-to-explode
Please add mb_split to "Confusion with other functions"
mbstring functions are typically designed so func and mb_func behave
similarly, just mb_ has multibyte support. Since the closest chance to
remove mb_split is PHP 9, the closest introduction for split would be
PHP 10 imho
--
Anton
2025年8月22日(金) 22:49 Anton Smirnov sandfox@sandfox.me:
Hello, folks. As discussed in previous messages [1], I am proposing
the creation of an alias functionsplitto theexplodefunction.Here is the RFC for discussion:
https://wiki.php.net/rfc/create-split-alias-to-explodePlease add mb_split to "Confusion with other functions"
mbstring functions are typically designed so func and mb_func behave
similarly, just mb_ has multibyte support. Since the closest chance to
remove mb_split is PHP 9, the closest introduction for split would be
PHP 10 imho--
Anton
Hi,
mb_split is depends on Oniguruma.
Oniguruma is end of maintenance in 2025-04-24.
I created an RFC, I want to deprecate 8.x and remove 9.0.
Please see below:
https://wiki.php.net/rfc/eol-oniguruma
Regards
Yuya
--
Yuya Hamada (tekimen)
Thank you both. I added the mb_split section mentioning this RFC to
deprecate (and remove) it.