Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125827
Precedence: bulk
MIME-Version: 1.0
References: <ZydAaayECTRNG8Ackhb0tDgYjmdFKnkW4p0ISWlLFP5My4CsJBR1KKTylrD14Ags2GUyBLoJPf68N6Z6LoVzjG-tru8YAbmi74W5xzSkJ8I=@gpb.moe>
 <y61nFg8JnfpzCsL25kyI35RiCtTm7MHW_Zn3TY81lKHkmdagnyTMk0f73FQV-xuu1aRl4401vOtG5ZbK5j5Xx4_UCkF1TJnoGNm2Aw4GlSw=@gpb.moe>
 <CAPyj-LDbEYXYDROO5_M1WZWUw1pCWhhVREEvqgQuHGXTBLpaHw@mail.gmail.com>
 <HRchGMNN6j5OCtAss04zESt4UVSCxl5qka3EFDnARx-_0cqXsF7W7IOOI6OXZiuG0e-FLpALPeHGTV0qWw9WbHApmrGdN5y9OBmgpzwTCmw=@gpb.moe>
 <CAPyeZ4NnoJU0FKFGPOg+KFYmQgabCCuG8Owh6V-5DTCDEru8QA@mail.gmail.com>
In-Reply-To: <CAPyeZ4NnoJU0FKFGPOg+KFYmQgabCCuG8Owh6V-5DTCDEru8QA@mail.gmail.com>
Date: Tue, 22 Oct 2024 06:41:53 +1000
Message-ID: <CAKVXxD9xC8OuKAoLcUu_-Bic9XjhP9_Y63wzj-+PtX-NUwn0Lw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Change behaviour of array sort functions to
 return a copy of the sorted array
To: Valentin Udaltsov <udaltsov.valentin@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000861ebf062502af92"
From: mickmackusa@gmail.com (mickmackusa)

--000000000000861ebf062502af92
Content-Type: text/plain; charset="UTF-8"

On Tue, 22 Oct 2024, 02:30 Valentin Udaltsov, <udaltsov.valentin@gmail.com>
wrote:

>
> What if instead of this proposal we reimplement all of the array
> functions in a different namespace and fix a lot of other problems and
> inconsistencies?
>
> Array\map(iterable $iterable, callable $mapper): array
> Array\sort(iterable $iterable, int $flags = SORT_REGULAR): array
> ...
>
> --
> Valentin


Getting off-topic here, but array_map()'s parameter order matters.  Because
it can receive one or more arrays, the callback should be the first
parameter to afford, say, spreading the rows of a multidimensional array
during transposition.  The same "spreadability" logic should apply to
array_*diff*(), array_*intersect*(), and array_multisort().  If we were
going for consistency, always write callbacks as the first parameter for
any function that has one. In other words, parameters which can be repeated
more than once must be list as the last parameter.

It is clear that this RFC is seeking success by making the smallest
possible, very practical change. While it is healthy to explore deviations,
I like the RFC on it's own because it makes PHP more adaptable to writing
elegant code with fewer temporary variables.

Mick

>

--000000000000861ebf062502af92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Tue, 22 Oct 2024, 02:30 Valentin Udaltsov, &lt;<a href=3D"m=
ailto:udaltsov.valentin@gmail.com">udaltsov.valentin@gmail.com</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><br>
What if instead of this proposal we reimplement all of the array<br>
functions in a different namespace and fix a lot of other problems and<br>
inconsistencies?<br>
<br>
Array\map(iterable $iterable, callable $mapper): array<br>
Array\sort(iterable $iterable, int $flags =3D SORT_REGULAR): array<br>
...<br>
<br>
-- <br>
Valentin</blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Getting off-topic here, but array_map()&#39;s parameter order matters.=
=C2=A0 Because it can receive one or more arrays, the callback should be th=
e first parameter to afford, say, spreading the rows of a multidimensional =
array during transposition.=C2=A0 The same &quot;spreadability&quot; logic =
should apply to array_*diff*(), array_*intersect*(), and array_multisort().=
=C2=A0 If we were going for consistency, always write callbacks as the firs=
t parameter for any function that has one. In other words, parameters which=
 can be repeated more than once must be list as the last parameter.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">It is clear that this RFC is se=
eking success by making the smallest possible, very practical change.  Whil=
e it is healthy to explore deviations, I like the RFC on it&#39;s own becau=
se it makes PHP more adaptable to writing elegant code with fewer temporary=
 variables.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Mick</div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000861ebf062502af92--