Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC][Vote] iterable_to_array() and iterable_count()

Posted by Michael Moravec 
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.
Christoph M. Becker
[PHP-DEV] Re: [RFC][Vote] iterable_to_array() and iterable_count()
July 04, 2018 12:00AM
On 03.07.2018 at 22:48, Michael Moravec 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

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 <[email protected]>:

> On 03.07.2018 at 22:48, Michael Moravec 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
>
> 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
>
Christoph M. Becker
[PHP-DEV] Re: [RFC][Vote] iterable_to_array() and iterable_count()
July 04, 2018 12:30AM
On 04.07.2018 at 00:11, Michael Moravec wrote:

> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2018-07-04 0:23 GMT+02:00 Christoph M. Becker <[email protected]>:
>
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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


On 04/07/2018 00:44, Michael Moravec wrote:
> 2018-07-04 0:23 GMT+02:00 Christoph M. Becker <[email protected]>:
>> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Jul 3, 2018 at 10:48 PM, Michael Moravec <[email protected]>
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 16:43 GMT+02:00 Jordi Boggiano <[email protected]>:

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

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2018-07-05 22:35 GMT+02:00 Nikita Popov <[email protected]>:

> 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 with iterator_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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Jul 3, 2018 at 9:48 PM Michael Moravec <[email protected]> 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.
>
>
> 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 <[email protected]>:
> On Tue, Jul 3, 2018 at 9:48 PM Michael Moravec <[email protected]> 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.
>>
>>
>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login