Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124110
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <7f1ba41b-ace8-4af2-8efc-1412c47e34cb@app.fastmail.com>
In-Reply-To: <3B23E039-D90F-4F84-9ECE-C6A9A3E145AF@sakiot.com>
References: <F709ADD3-502E-418B-82D3-34A681EBB7A0@sakiot.com>
 <668168A7.4040005@adviesenzo.nl>
 <e4a3fba1-e441-4f35-ac17-462f5f9c3fb9@app.fastmail.com>
 <3B23E039-D90F-4F84-9ECE-C6A9A3E145AF@sakiot.com>
Date: Sun, 30 Jun 2024 10:43:01 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jun 30, 2024, at 10:11 AM, Saki Takamachi wrote:
> Hi,
>
>>> Just a suggestion: what about making the returned array an associati=
ve
>>> array ? Like so:
>>> ```
>>> array(
>>>      'quotient' =3D> 61,
>>>      'remainder' =3D> 1,
>>> );
>>> ```
>>> This would remove the need for devs to remember the order of the ret=
urn
>>> values and would make the return value self-documenting.
>>=20
>> An associative array would combine the worst of an array (no IDE auto=
completion, no strong typing, increased memory usage) with the worst of =
an object (no easy way to extract the values into local variables with a=
rray destructuring).
>>=20
>> The example in the RFC doesn't show it, but the following makes the p=
roposed API really convenient to use:
>>=20
>>    $slicesOfPizza =3D new BcMath\Number(8);
>>    $mouthsToFeed =3D new BcMath\Number(3);
>>    [$perMouth, $slicesLeft] =3D $slicesOfPizza->divmod($mouthsToFeed);
>>=20
>> Note how the order of values matches the words in the method name. Fi=
rst the result of 'div', then the result of 'mod=E2=80=99.
>
>
> Thanks, I have added this example to the RFC (Please let me know if yo=
u=20
> have any problems).
>
>
>> I came here to say the same thing. The best solution would be not hav=
ing to refer to documentation or experiment with values, and this hits t=
he nail on the head.
>>=20
>> The only thing that makes it weird is having to write it out, which a=
t that point, it is probably faster to type out bcdiv and bcmod separate=
ly.
>>=20
>> Have you considered simply using references passed to the function? I=
 feel like that is more idiomatically php.
>
> Of course, that idea was proposed, but it was pointed out that current=20
> PHP tends to avoid such implementations, so we didn't adopt it. The=20
> reason why passing by reference was not adopted was added to the RFC.
>
> Regards,
>
> Saki

I agree an associative array is the second-worst option.  An inout by-re=
f argument is the absolute worst.

Normally my default position is that when in doubt, make it a structured=
 object with properly defined properties, and screw whatever micro-perfo=
rmance hit it is, you won't notice.  99% of the time I believe that is t=
he correct approach.

I can see the argument that this is the other 1%, since it's just two va=
lues, which will basically always be wanted separately but both wanted (=
meaning divmod(...)->divsor is kinda pointless), and their order should =
be fairly self-evident.

However, in that case I would urge that both the RFC and the resulting d=
ocumentation *always* use examples that return into a `[$foo, $bar]` des=
tructured list.  Don't even suggest that people should use 0 and 1 index=
es.  It's a tuple for deconstruction, that's it, if you're using it some=
 other way you're probably wrong.  Politely ignore that it's even possib=
le, lest we lead people down the dark path.

(Which means removing the current index-using example and just keeping t=
he pizza example.)

--Larry Garfield =20