Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open for
voting:
https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
Thank you,
M.
Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open for
voting:https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
Thanks for the RFC, Michael!
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
That's nasty close to the scheduled branching of PHP-7.3 (i.e. feature
freeze). Assuming an appropriate (depending on the outcome of the
iterable_count() vote) PR or patch could be merged on 01:00 UTC, I'd
still wait for the Travis and Appveyor builds which may take an hour.
That would be 4pm for me to actually start the branching and tagging
process – still fine, but what if there would be any further delay?
I would prefer that any votes on RFCs targeting 7.3 would end some hours
or even day earlier than 2018-07-17 12:00 UTC, if possible.
--
Christoph M. Becker
Hi Christoph,
I wanted to keep it within the standard 14 days long period
both for discussion and voting.
If there are no objections (no votes yet), we can shorten it
i.e. to 2018-.07-16 23:00 UTC - would that work for you?
Thanks!
M.
2018-07-03 23:52 GMT+02:00 Christoph M. Becker cmbecker69@gmx.de:
Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open
for
voting:https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
Thanks for the RFC, Michael!
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
That's nasty close to the scheduled branching of PHP-7.3 (i.e. feature
freeze). Assuming an appropriate (depending on the outcome of the
iterable_count() vote) PR or patch could be merged on 01:00 UTC, I'd
still wait for the Travis and Appveyor builds which may take an hour.
That would be 4pm for me to actually start the branching and tagging
process – still fine, but what if there would be any further delay?I would prefer that any votes on RFCs targeting 7.3 would end some hours
or even day earlier than 2018-07-17 12:00 UTC, if possible.--
Christoph M. Becker
I wanted to keep it within the standard 14 days long period
both for discussion and voting.
If there are no objections (no votes yet), we can shorten it
i.e. to 2018-.07-16 23:00 UTC - would that work for you?
Yeah, I'd prefer that. It's not that 2018-07-17 12:00 UTC couldn't
work – it's just I'd rather have some buffer time (I presume there will
be more RFCs whose voting ends close to feature freeze).
Thanks, Michael, anyway!
--
Christoph M. Becker
2018-07-04 0:23 GMT+02:00 Christoph M. Becker cmbecker69@gmx.de:
Yeah, I'd prefer that. It's not that 2018-07-17 12:00 UTC couldn't
work – it's just I'd rather have some buffer time (I presume there will
be more RFCs whose voting ends close to feature freeze).
Alright, updated!
RFC voting now closes on 2018-07-16 23:00 UTC.
M.
Hey,
Just to explain the No vote for iterable_count, I think we'd rather
advocate people implement Countable in their iterables than to force the
consumption of an iterator just to count it as this can have
side-effects and render the iterator unusable. If Countable is
implemented then count() will do the job and all is well. If consuming
the iterator is desired then one still can do
count(iterable_to_array($iter)) fairly easily.
Best,
Jordi
2018-07-04 0:23 GMT+02:00 Christoph M. Becker cmbecker69@gmx.de:
Yeah, I'd prefer that. It's not that 2018-07-17 12:00 UTC couldn't
work – it's just I'd rather have some buffer time (I presume there will
be more RFCs whose voting ends close to feature freeze).
Alright, updated!
RFC voting now closes on 2018-07-16 23:00 UTC.M.
--
Jordi Boggiano
@seldaek - https://seld.be
2018-07-05 16:43 GMT+02:00 Jordi Boggiano j.boggiano@seld.be:
Just to explain the No vote for iterable_count, I think we'd rather advocate
people implement Countable in their iterables than to force the consumption
of an iterator just to count it as this can have side-effects and render the
iterator unusable. If Countable is implemented thencount()will do the job
and all is well. If consuming the iterator is desired then one still can do
count(iterable_to_array($iter)) fairly easily.
Hi,
I absolutely agree. I initially started writing the RFC without
iterable_count(),
but later I decided to include it for completeness, so that both iterator_*()
functions have a proposed alternative.
Of course, and for the reasons mentioned I made a vote for each of
them separately.
M.
On Tue, Jul 3, 2018 at 10:48 PM, Michael Moravec php.net@majkl578.cz
wrote:
Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open for
voting:https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
I voted against both functions. Jordi already explained why
iterable_count() is questionable, so let me add a comment regarding
iterable_to_array().
Essentially my gripe is that I'm not convinced of the usefulness of this
function and am concerned that it might be encouraging bad practices. In
particular:
- As the RFC already mentions, iterable_to_array() can be replaced by a
simple and in my eyes very clear one-liner. This pattern would have to be
extraordinarily common to justify adding a function for it. - The operation iterable_to_array() should be rare. Please do not accept
iterable arguments if you are not just iterating over them. If your
operation requires conversion to array, then directly accept an array,
otherwise you are making false promises. If you want to use an array
function on an iterable -- don't. Reimplement the function to work with
iterables or use a library that does. - The very close names of
iterator_to_array()and iterable_to_array() are
somewhat confusing. For type declarations "iterable" and "Iterator" are
quite distinct due to different capitalization, but the functions are hard
to distinguish at a glance.
An additional issue is that iterable_to_array() preserves the behavior of
iterator_to_array() to preserve iterator keys by default, which is a big
footgun, especially in combination with generators. However, I also
understand that using a different default would be even worse, due to the
confusion with iterator_to_array().
Regards,
Nikita
2018-07-05 22:35 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
I voted against both functions. Jordi already explained why iterable_count()
is questionable, so let me add a comment regarding iterable_to_array().Essentially my gripe is that I'm not convinced of the usefulness of this
function and am concerned that it might be encouraging bad practices. In
particular:
- As the RFC already mentions, iterable_to_array() can be replaced by a
simple and in my eyes very clear one-liner. This pattern would have to be
extraordinarily common to justify adding a function for it.
Now imagine a large codebase with 50 occurences. Then multiply this by 1000
projects. That is a lot of "simple oneliners" with a lot of place for
potential errors.
In the end this is not different from is_countable() which was
unanimously accepted.
The pattern is not common yet because iterable is not common yet. One of the
show-stoppers is incompatibility with array functions (or array hints
in general).
- The operation iterable_to_array() should be rare. Please do not accept
iterable arguments if you are not just iterating over them. If your
operation requires conversion to array, then directly accept an array,
otherwise you are making false promises. If you want to use an array
function on an iterable -- don't. Reimplement the function to work with
iterables or use a library that does.
Unfortunately, this is not true in real world, mostly due to BC and
compatibility.
- The very close names of
iterator_to_array()and iterable_to_array() are
somewhat confusing. For type declarations "iterable" and "Iterator" are
quite distinct due to different capitalization, but the functions are hard
to distinguish at a glance.
I disagree, but I also believe this is a matter of taste/preference.
An additional issue is that iterable_to_array() preserves the behavior of
iterator_to_array()to preserve iterator keys by default, which is a big
footgun, especially in combination with generators. However, I also
understand that using a different default would be even worse, due to the
confusion withiterator_to_array().
Whether it's true or not, thatt's what iterator_to_array() does, and
the behavior is neither deprecated nor adviced against in documentation.
If you want to deprecate keyed iterator_to_array(), let's do it in 7.4,
but I don't see how this makes this very RFC "bad", just by preserving
behavior for consistency.
Right now, it sounds like advocating the introduction of yet another
inconsistency, something that PHP is very often being disliked for.
Thanks,
M.
Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open for
voting:https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
Thank you,
M.
Hi,
I'd like to point out that a cast to array could almost replace the first
one-liner example in the RFC, with the exception of the generator case. It
may be an issue that (array)$iterator has a different behavior than
iterator_to_array($iterable) but that would be a separate discussion.
Regards,
Pedro
Hi,
the RFC has been declined.
Thank you for voting, and especially thanks to Jordi and Nikita
for explaining their No vote, unlike the rest of No-voters.
Thank you,
M.
2018-07-09 22:13 GMT+02:00 Pedro Magalhães mail@pmmaga.net:
Hello internals,
The RFC for adding iterable_to_array() and iterable_count() is now open
for
voting:https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
You can vote for each function separately.
Voting will close on 2018-07-17 12:00 UTC.
Thank you,
M.Hi,
I'd like to point out that a cast to array could almost replace the first
one-liner example in the RFC, with the exception of the generator case. It
may be an issue that (array)$iterator has a different behavior than
iterator_to_array($iterable) but that would be a separate discussion.Regards,
Pedro