Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102616
Return-Path: <nikita.ppv@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 20975 invoked from network); 5 Jul 2018 20:35:09 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 5 Jul 2018 20:35:09 -0000
Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
X-PHP-List-Original-Sender: nikita.ppv@gmail.com
X-Host-Fingerprint: 209.85.223.173 mail-io0-f173.google.com  
Received: from [209.85.223.173] ([209.85.223.173:40253] helo=mail-io0-f173.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 7C/C6-55607-9F08E3B5 for <internals@lists.php.net>; Thu, 05 Jul 2018 16:35:07 -0400
Received: by mail-io0-f173.google.com with SMTP id t135-v6so8938179iof.7
        for <internals@lists.php.net>; Thu, 05 Jul 2018 13:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc;
        bh=RilDJSUkaRTUQUCM7MsfOCXA2VFO2K/4q1PFFNNki/0=;
        b=NWAXLI+RaFbe2anBWmPbkddbXpiiSlPXk7XL5ll8gN6rAJP/wpdb4VVUQ3xtr/N29g
         NOAg4W8axLimHQyxt0ELR3M29LoHS2H4UPlvhrDxhLR/l6h5VcCe0+RO1UO+vXD6jpf0
         M1ePtEQnjXP/gahUl98CfP+hFaHbfgfhPA+BAya3/CVK0krE5+oGZv0t8sQ/A8VcXrTr
         WGvOFSdj5R1heCtZcdxWm+rSlsdtTPY4TA3vVsYK4iYrc+WouVHb5gRglu0NDORiuStx
         nn1O7/TBRxfGFIuGj/7BRI3tiL5YcRoTrEs5Di4si5TZme6J03hMM5I2QdTtlxW3f8k2
         lyxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=RilDJSUkaRTUQUCM7MsfOCXA2VFO2K/4q1PFFNNki/0=;
        b=B6E2wSPSfXubVpCi07kU7Q128Z28pFKUermctefXRQhNUWKfYVT8LccQNlvZ048ZNI
         zjEgm7bWhVNoLPGHwdmWkLTKpbBo4Lh+oWNamzxeHf66hDTG67yob4EEm1mOHgP9k53P
         nDRgRVmznQV4tI3nyYZKjgNOtXSVpjXS9tTwdoZdqZicURk7E4Zl9dcTo0lWTtxoqcvb
         5P6PoI9dx6/1/aotdYdS5l0vIdpoqe8brdA760UMkW1AjUUMY0+sW3X1qgum6vXClAc5
         PRp1SlaE5RQXNlX4lgPaDqJa3YpDLm4/IQo830IBfZ4dMzHSjlA0DClROYdGG8ejkbJz
         2/vw==
X-Gm-Message-State: APt69E0uljQWst/HDuBF+vHjRbB150ZEp6BDU3nwNkVtRP7bq/r30WLc
	mCEK4CjkvT6VUCKElTN7Yhs4C0elqFlood7twzD6fg==
X-Google-Smtp-Source: AAOMgpehePq6VSxQgKkdmy6vlII8bDvE4O3n52ZRxqyQMEK9m/vWXXCF5B1UgDf46tUuGauMZIO3cIwNuUA4UE/pVPk=
X-Received: by 2002:a6b:254e:: with SMTP id l75-v6mr5954760iol.47.1530822902501;
 Thu, 05 Jul 2018 13:35:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a6b:148a:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 13:35:02 -0700 (PDT)
In-Reply-To: <CAO7eTqNUo8Oy+D7PUO7acNL05EHiXdosRCZS2agiawu6JxV5+w@mail.gmail.com>
References: <CAO7eTqNUo8Oy+D7PUO7acNL05EHiXdosRCZS2agiawu6JxV5+w@mail.gmail.com>
Date: Thu, 5 Jul 2018 22:35:02 +0200
Message-ID: <CAF+90c9RB=mMD=4WsbDJMu=iyh-SO90U7TzHrh-VGjQyCLR2eg@mail.gmail.com>
To: Michael Moravec <php.net@majkl578.cz>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005158400570467b42"
Subject: Re: [PHP-DEV] [RFC][Vote] iterable_to_array() and iterable_count()
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000005158400570467b42
Content-Type: text/plain; charset="UTF-8"

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

--0000000000005158400570467b42--