Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112780 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28492 invoked from network); 6 Jan 2021 15:21:31 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Jan 2021 15:21:31 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E45571804E2 for ; Wed, 6 Jan 2021 06:57:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 6 Jan 2021 06:57:59 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id h22so7211097lfu.2 for ; Wed, 06 Jan 2021 06:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RhjJRmHopzr0p7pnmgBMm+ZAUE1t3oy7KORWoUd2Xl8=; b=SNvGgzO1nkk8K1hqzd2FYQjleDGnMXwZV1h3vDFWQ01C4hBO/U9ZBAmsT6eLY9Rxib tBRbjJzM2SDiUwRUhCcTtx42+1sO+agAbmf/iVQR26urxQZp7zmIS10FcPhQFndci+9A TgVIGM77fvytjyEdK2bEQqzMXvieDVg6Lk2/hc98rFi/EOl9wXU2WOyIU+jeWYnXypQO Cw1spQ+c3dKOzjAkcOWNK50hadMouhxJ6+Sa63fU/+1J91ILtyWwCk+KPjupC2L/t95n jZwUi+A/S4hcsNbXQjvrJOolAtmiAc0piR+TDdYhJhoEFEozDZugr/K01ujEmeWWp0aT IX9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RhjJRmHopzr0p7pnmgBMm+ZAUE1t3oy7KORWoUd2Xl8=; b=DIHnmH8uaM6xAkZdSzLMV+fh/dvwEvKgwC7Zl1/xhNuE90RU+r5JxpnvhR5aLJPi/0 Z3Ith7PYMxgaSs+jN7CNMDj5PIetaXm2//miUvl/xa2ijfec7BeafpEvo/cNRh7GY+Cv m1IkCXDPiTXdfnFNAy9jNMzPa9PABcoIkxBNI+OG0E1XOk33hmHVJ92VPINPCl4bjwvC WIna567OxslM1Xzk/ap6YJpZ8jObuAKbDTdb5Y4p6H3PYHH5e1htzOB2cc4OJ82ZUQ7O AB1LwsLMOMPaQheW6AKJ06gZmYKg4v4u/BXqg9SsPiga4pz0i4oe6XN1S2tF+vgHzeBx a6Kg== X-Gm-Message-State: AOAM533OKdf8KmLaK1eLKI28r5Vmy9bl+UXVnjx9HJTzZh2JeAmquc2q WFbndG8LNoGFUeGjdzyLUdRAV32hElCIMkVKKBI= X-Google-Smtp-Source: ABdhPJzRNJLN1UEI5ErFYS5lGPndnfCES0h/ONSrGaz8qweHjmf8sezxoQB+pn1yKPdS0s17pLDlGpOmzMBprnZ/KSA= X-Received: by 2002:a19:2d0a:: with SMTP id k10mr2189228lfj.286.1609945077607; Wed, 06 Jan 2021 06:57:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 6 Jan 2021 15:57:41 +0100 Message-ID: To: Levi Morrison Cc: tyson andre , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="00000000000075740805b83c8c7f" Subject: Re: [PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables From: nikita.ppv@gmail.com (Nikita Popov) --00000000000075740805b83c8c7f Content-Type: text/plain; charset="UTF-8" On Wed, Jan 6, 2021 at 3:40 PM Levi Morrison wrote: > On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov wrote: > > > > On Wed, Jan 6, 2021 at 2:28 AM tyson andre > > wrote: > > > > > Hi internals, > > > > > > > I've created a straw poll for the naming pattern to use for `*any()` > and > > > `*all()` on iterables. > > > > https://wiki.php.net/rfc/any_all_on_iterable_straw_poll > > > > > > > > Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable > > > proposes adding only two functions, > > > > but more functionality acting on iterables (array|Traversable) may be > > > added in the future, > > > > making it important to get feedback what people feel the best choice > of > > > naming pattern would be > > > > to avoid inconsistency or name changes later on. > > > > (Many alternatives were suggested in the initial RFC announcement - > > > https://externals.io/message/111756) > > > > > > I've received more feedback than I expected from voters that were > strongly > > > or moderately > > > in favor of putting new categories of functionality in namespaces. > > > > > > I've started a different straw poll and plan to start voting on that on > > > the 8th (this will be the last straw poll for iterable function naming > for > > > this RFC) > > > https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace > > > > > > 1. I plan to propose additional internal functions for working with > > > iterables if this succeeds, > > > and would want to be sure this is the best name choice instead of > just > > > an acceptable name choice going forwards. > > > 2. Additionally, this has been an opportunity for measuring overall > > > interest in adopting namespaces for brand new categories of > functionality. > > > It can be argued that this is a new category of functionality > because > > > existing methods work on Traversables (iterator_*) or arrays > (array_*), but > > > generally not both. > > > (classes such as https://www.php.net/manual/en/class.ffi-cdata.php > have > > > adopted namespaces, > > > but no global functions in php-src that I'm aware of have adopted > > > namespaces yet) > > > > > > > I'm happy to have these functions namespaced, but I'm not sure the > > suggestion to namespace them under Spl makes sense. This functionality > has > > fairly little to do with the SPL as it is now and to be honest, by now > > there is quite a bit of ... stigma associated with functionality that > > resides in SPL. > > > > I would suggest using iterable\any and iterable\all as the names if we > want > > to go down this route. iterable_any and iterable_all were the by far most > > popular choices on the previous poll, and these are just the namespaced > > variants thereof. > > > > Regards, > > Nikita > > On the contrary, I'm happy to accept it into the SPL. I don't want the > SPL to be a dumping ground for everything, but I specifically > requested it to be an option for this vote. > Using *just* the SPL namespace (that is, SPL\any) makes the SPL namespace a dumping ground for everything, as you said. Once you introduce an additional meaningful namespace in the form of SPL\iterable\any, you are better off either dropping the SPL part and arriving at iterable\any, or replacing SPL with something more sensible and arriving at PHP\iterable\any. TBH I think Tyson's original approach of not including namespaces as a possibility was the right one. We clearly still don't have any consensus on how to structure namespaces in PHP extensions and it doesn't seem like a question that should be resolved as a footnote of another RFC. There have been multiple RFCs one the topic, and none of them reached anything even approaching a consensus. Regards, Nikita --00000000000075740805b83c8c7f--