Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125818 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id B83D11A00BD for ; Mon, 21 Oct 2024 01:13:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1729473373; bh=W5OSZa1ZWWsvDHGK3t7g2If++FmcS2Mbto3owsSK6Yk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Pgb0TUMIYaM8AjPZVLRJIhhNsYD4BMMP6ICN1Z3fJ+anvbZL1BL/LtIC5ZEin1FaV HNeAW6+CeW8vvT3e8euvUzIu1QNTiQWH91+llcXK+nyOsyLNRg22XadDCueDdsDsgs Px1PXTy1Ie0XFjI7FBcclCrO/ThcNDfOfmq/EmL4T8+sU/RMvAw8TSHCtfx7gVgqsM 1738J3NvKlbH3Tzi4nnFMsfCzLRk2ulywbmLL69Aabf33p8c49+u3VEZD1zNxMAtiy Oi8oUKmqv3oeOPwhA+lzeurn76zWNtjNnSbY1fUHrjDZ3RfiTMaMHV4TuaIquOUkem 7Nk4bsmwcVkyg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1574518004F for ; Mon, 21 Oct 2024 01:16:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 21 Oct 2024 01:16:12 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a99f629a7aaso696348166b.1 for ; Sun, 20 Oct 2024 18:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729473228; x=1730078028; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=380rDi1oZTWiqHy42OWpKpJxLimJKsbnbcYlB7/hjHo=; b=CsCIjsC4ic/FEb7Kkx9zx4Kk8qfPgumNfvsZ3w8A6Qwk6Ws6NxfrNCP3Hqnq0uduw6 mMQOH4RCHKXdrAeCsFUQ645u6qqgI8oUqfvkIyO4n8QkAxGJ9adtcxgY3QJRAz/J6ZhA CFViGGxhKynC1xdcqGP0iPevFWwd5Zg0B/zpe8v6R4wtSSW0p1MPm9+52/bl2ufQ3T13 MMs7Ltd0AX/xXuUXPqIzGsm8i+e/2u8q/2XdpC6B8LhaX09WuMoJ2M9D9ue9s2fftS3I MjUMb/DVP8pWH/FMZqjRcQLWR/ZeaA9w0fXdWX0dW/Uwe410pB+PWVDo4SmzZ3P7JO1g cdOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729473228; x=1730078028; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=380rDi1oZTWiqHy42OWpKpJxLimJKsbnbcYlB7/hjHo=; b=pvNiSAAsLJ8Jn0r2k5y6m0383QePS86LBvxqalgAKFnJSPce/b2sjFhFpR/qIrDifr 818aFQQGxEQY4FE2Myv1KCwRODgyVPP6JOcXkH8yRrtzBNnsF5ZFBTam4wTbxCkJ2hKN xbCjUhfLFV594YeVq3Mody3AxCpMFisjv9BpYFCUMqegQuIZryvc3xLW54iNg8NrkTWk 4FtvO0s5ypJJaPM3nbTcv2geYRhSqc/WCaxFGlAFea0wg1vbGJUtiDPUC9eJbbZUsund pn4xUy6+npx/uYKEovGvwWVDotw8a2Ro0D6EpC51oU/RYImMcWLtBtJhIJiJXLry7uU/ 1jCA== X-Gm-Message-State: AOJu0Yya/NJJPSegSN47ERZbd5SaJhspXeiiMTX9Nwq5zae0nA+NJoDH A6++RQEKc7zV8T2LCFd737TC3Xd4XM9FrmAr46pdTHfqMf2EzLX1zHA6m6aT9719GV0TQCCOp8q 6/zAhyK09koh1/ct7gXmE0DGIsH8= X-Google-Smtp-Source: AGHT+IH1slF0LdF7+VGbbyydm75fqGWQkGbteNbeYetF4iST5jB3FHlzPnxkYmNymSddvzKhS4kWw7zMfZn6ZdE6cOs= X-Received: by 2002:a17:907:2da3:b0:a99:f722:2dde with SMTP id a640c23a62f3a-a9a4c2c5f38mr1524253666b.1.1729473227461; Sun, 20 Oct 2024 18:13:47 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <00f19678-bbd1-49e1-99f6-8a9b78b962aa@scriptfusion.com> In-Reply-To: <00f19678-bbd1-49e1-99f6-8a9b78b962aa@scriptfusion.com> Date: Mon, 21 Oct 2024 11:13:35 +1000 Message-ID: Subject: Re: [PHP-DEV] [RFC] Change behaviour of array sort functions to return a copy of the sorted array To: Bilge Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000005f1bf20624f25d40" From: mickmackusa@gmail.com (mickmackusa) --0000000000005f1bf20624f25d40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2024 at 10:19=E2=80=AFAM Bilge wro= te: > On 21/10/2024 00:16, mickmackusa wrote: > > Might the transition be simpler if the naming convention is standardized > to have array_ meaning "returns the input [sorted|shuffled|traversed] > array" and without the prefix means "modify by reference"? > > That naming convention will not look absurd among other native array_ > functions and prefix-trimmed functions will afford developers to continue > using the original modify by reference behavior (if they have performance > or memory reasons). > > | returns copy of array | by reference | > | ---------------------- |---------------- | > | array_sort() | sort() | > | array_rsort() | rsort() | > | array_asort() | asort() | > | array_arsort() | arsort() | > | array_ksort() | ksort() | > | array_krsort() | krsort() | > | array_natsort() | natsort() | > | array_natcasesort() | natcasesort() | > | array_usort() | usort() | > | array_uasort() | uasort() | > | array_uksort() | uksort() | > | array_multisort() | multisort() | > | array_shuffle() | shuffle() | > | array_walk() | walk() | > | array_walk_recursive() | walk_recursive() | > > Good luck regardless, > mickmackusa > > I like this in theory, but array_multisort() and array_walk*() already > broke your proposed convention :( > > Cheers, > Bilge > Yes, the RFC was already intending to break backward compatibility to a small degree. I am suggesting that multisort(), walk(), and walk_recursive() be defined in the language so that users disrupted by this change can do a simple search-replace in their applications. This way, all of the array_*() functions can be defined or altered to return a copy. I acknowledge the high likelihood that existing projects may already have helper functions like walk(), walk_recursive(), and multisort(), but this again is resolved by a simple search-replace. I do not know if there is any appetite to have the array_*() functions NOT modify by reference at all. That would be a much larger break. Maybe that could be a future consideration set up by this distinction in naming convention. Having array_walk*() return an array would mark a significant change in my functional iteration decision making. Because array_walk*() functions allow key access (and have the $arg third parameter), there will be places where I can enjoy array_walk() instead of passing an array of keys to array_map() or array_reduce() and return the modified array. I don't mean to push super hard for such changes, I just want to expand on available strategies so that relevant pathways can be discussed. p.s. Too distant from the concern of this RFC is my wish that array_walk($array, ksort(...)) and many other similar scenarios "worked". https://stackoverflow.com/q/11399741/2943403 (sorry for double email you Bilge, I failed to reply-all) Mick --0000000000005f1bf20624f25d40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2024 at 10:19=E2=80=AFAM = Bilge <bilge@scriptfusion.com<= /a>> wrote:
=20 =20 =20
On 21/10/2024 00:16, mickmackusa wrote:
=20
Might the transition be simpler if the naming convention is standardized to have array_ meaning "returns the input [sorted|shuffled|traversed] array" and without the prefix means "modify by reference"?

That naming convention will not look absurd among other native array_ functions and prefix-trimmed functions will afford developers to continue using the original modify by reference behavior (if they have performance or memory reasons).

| returns copy of array=C2=A0 | by reference=C2=A0 =C2=A0 |
| ---------------------- |---------------- |
| array_sort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| sort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
|=C2=A0array_rsort()= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0rsort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|
| array_asort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0=C2=A0asort()=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|
| array_arsort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0=C2=A0arsort()=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= =C2=A0|
| array_ksort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0=C2=A0ksort()=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|
| array_krsort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0=C2=A0krsort()=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|
| array_natsort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0=C2= =A0natsort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0|
| array_natcasesort()=C2=A0 =C2=A0 |=C2=A0=C2=A0natcasesort()=C2=A0 =C2=A0|
| array_usort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0=C2=A0usort()=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|
| array_uasort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0=C2=A0uasort()=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= |
| array_uksort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0uksort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| array_multisort()=C2=A0 =C2=A0 =C2=A0 |=C2=A0multisort()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|
| array_shuffle()=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0shuffle()=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| array_walk()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| walk()=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
|=C2=A0array_walk_recursive() | walk_= recursive() |

Good luck regardless,
mickmackusa

I like this in theory, but arr= ay_multisort() and array_walk*() already broke your proposed convention :(

Cheers,
Bilge



I do not know if ther= e is any appetite to have the array_*() functions NOT modify by reference a= t all.=C2=A0 That would be a much larger break.=C2=A0 Maybe that could be a= future consideration set up by this distinction in naming convention.

--0000000000005f1bf20624f25d40--