Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117585 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 86689 invoked from network); 24 Apr 2022 10:49:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Apr 2022 10:49:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 750781804E3 for ; Sun, 24 Apr 2022 05:24:31 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 ; Sun, 24 Apr 2022 05:24:30 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id r187-20020a1c44c4000000b0038ccb70e239so10861040wma.3 for ; Sun, 24 Apr 2022 05:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=dmMTUPrbocIrPQj3nQQNnX9EBlwNJ/sQDQV4XvHZ4dM=; b=P8wLnhHQufGdBhfMSXoyImciQdoQiiKe5Ck2GYR9qw7WQq+CBJsCMyN0+qdelpovHF pOT/WjQ0zmrm6d8WH+RHEdzEtMVU0KWPp34GYahhrtfNQ5avk8i6FcDjekTtAkObbVUV 9Hi3waaA5CYexOpxrb94arfWJPlYA8iw0CfYXxqRQOQlE7vV2jXkBTzoDVgqtw5MTgw2 2mXvRgw2I40dY1G70hjhtLu9HjknXGmrzXs9lH4QnqQHx8T/jbk9qwalLgtTujkI+ORQ u+sH7e+XbBow2ZsfBg17prZauQ5NL2nc7qNFcKywil6f2M4pBFJvlAtQjVuw+BWqT6jq oZjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=dmMTUPrbocIrPQj3nQQNnX9EBlwNJ/sQDQV4XvHZ4dM=; b=eLrmymGX51BPPakUDCvGBB5i8UrqOhSCr6TXswDWdqY8jRSH1gAZd58erA4k3WHnRC RLb0zkmpWU3+COpkY0agyHSGsGCH3SlBPWkgi7u2yGfE9+IkpopHh7rRnOH384Kmxi20 l7jsSC5/o6TKqIhR+3E/T6xUrLGRfFFNPtYnL/TOoZhL1EcxeAOxyxlUFKC8dQxe42ru AInm1jjIEcmTik2OYuwtjfmRpPI9bjHe8WXY+fEv/1lvpp8Lu5xdc2VIzX7wEErqHnhL GQputlLWREod/R0pnnDEFFTKJIchgeoBpj4fhIxhW4bCdovH0Ahdh8g3RVH7fiMiOVkx fYew== X-Gm-Message-State: AOAM5310vrt+fd6qGOkYTOfwXSBy6P6cK5iAvmBnSI8au+njF3OBQmmt s2eArASWWVQ7bFwYd129kFlmIMKpxnQ= X-Google-Smtp-Source: ABdhPJzS3JlkiZHmoluqTe/qu0gyFnccj5uPUTAWWlzrQsVdPcqUR/L0GWnghK2FkvKeR5g5AC5LjA== X-Received: by 2002:a05:600c:1d9f:b0:38e:d527:33fc with SMTP id p31-20020a05600c1d9f00b0038ed52733fcmr21298537wms.186.1650803069724; Sun, 24 Apr 2022 05:24:29 -0700 (PDT) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id h10-20020a05600c414a00b0038ebb6884d8sm8564400wmm.0.2022.04.24.05.24.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Apr 2022 05:24:28 -0700 (PDT) Message-ID: Date: Sun, 24 Apr 2022 13:24:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-GB To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Discussion before submission of array_transpose() RFC From: rowan.collins@gmail.com (Rowan Tommins) On 23/04/2022 23:42, mickmackusa wrote: > Ideally, PHP should have a native transposing function to put > developers out of their misery -- much like array_key_last() did. I think a better comparison would be array_column - https://wiki.php.net/rfc/array_column One interesting thing that Ben Ramsey wrote alongside that RFC was a pure PHP implementation with identical behaviour, available for use as a polyfill: https://github.com/ramsey/array_column Unlike array_column, I don't recall personally needing an array_transpose function, but am willing to believe that many people do. My first piece of advice would be to start with a definition of what you mean by "transpose" in this context, with an example of input and output in the basic case, and then a few scenarios where it's useful. Having that clear would then help understand the details you go into, each of which could be accompanied by its own example. For instance: > Let's create an intuitive transposing function for data sets with a > minimum depth of 2 levels. I can't picture what "transpose" means for something with more than 2 levels. > As a matter of flexibility, there should be no requirement that the > lone parameter be a matrix or dense data structure. I have no idea what this means. > It should also preserve keys to give it a clear advantage over > pre-existing functional techniques. Preserve what keys? > // [['single' => 'row']] becomes ['single' => 'row'] but should be > ['single' => ['row']] Should it? Why? My second piece of advice is to remember that flexibility, ease of use, and efficiency, are three corners of a triangle, and you can't optimise for all three. array_column does a reasonable job of covering multiple use cases, but there have been several unsuccessful requests over the years to enhance it or create variations for other use cases, so you're never going to make everyone happy. > Should the function unconditionally return an array of arrays? > Should it preserve the initial data types of the first and second level? > Should data type preservation be excluded to increase the chances of > its implementation? > [...] > 1. Unconditionally cast output as array of arrays. > [...] > 2. Preserve original data types of level one and level two. > https://3v4l.org/RRKlr > > (If input is two dimensional, then the first occurring data type in > the second level will dictate the result's first level data type.) > [...] > If only initially implemented to return an array of arrays, then > expanding the result data types in the future may be of interest. Without really understanding what you're saying, my suspicion is that these paragraphs are trying too hard to make a Swiss-army knife rather than a sharp blade. > List of Stack Overflow pages which seek to implement transposition Would all of these requirements be satisfied by the same implementation, without needing a complex set of options? What can we learn from the links about what features are likely to be most useful to people? I look forward to seeing a draft RFC, which can take the time to explain the features you think are needed. Regards, -- Rowan Tommins [IMSoP]