Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116063 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 75590 invoked from network); 17 Sep 2021 08:34:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Sep 2021 08:34:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id F3D9C1804DB for ; Fri, 17 Sep 2021 02:14:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS16276 94.23.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (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 ; Fri, 17 Sep 2021 02:14:35 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id E68FC5101324; Fri, 17 Sep 2021 09:14:22 +0000 (UTC) Message-ID: Date: Fri, 17 Sep 2021 11:14:21 +0200 MIME-Version: 1.0 Content-Language: en-US To: tyson andre , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP From: pierre-php@processus.org (Pierre) Le 17/09/2021 à 04:09, tyson andre a écrit : > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add `final class Vector` to PHP. Hello, That's nice, and I like it, but like many people I will argue about the API itself. One thing is that there's many methods in there that would totally fit generic collection common interfaces, and in that regard, I'd be very sad that it would be merged as is. I think it's taking the problem backwards, I would personally prefer that:  - This RFC introduces the vector into a new Collection namespace, or any other collection/iterable/enumerable related namespace, that'd probably become the birth of a later to be standard collection API.  - Start thinking about a common API even if it's for one or two methods, and propose something that later would give the impulsion for adding new collection types and extending this in order to be become something that looks like a really coherent collection API. If this goes in without regarding the greater plan, it will induce inconsistencies in the future, when people will try to make something greater. I'd love having something like DS and nikic/iter fused altogether into PHP core, as a whole, in a consistent, performant, with a nice and comprehensive API (and that doesn't require to install userland dependencies). I know this vector proposal is not about that, but nevertheless, in my opinion, it must start preparing the terrain for this, or all other RFC in the future will only create new isolated data structures and make the SPL even more inconsistent. Regards, -- Pierre