On Sun, Jun 30, 2024, at 10:11 AM, Saki Takamachi wrote: > Hi, > >>> Just a suggestion: what about making the returned array an associative >>> array ? Like so: >>> ``` >>> array( >>> 'quotient' => 61, >>> 'remainder' => 1, >>> ); >>> ``` >>> This would remove the need for devs to remember the order of the return >>> values and would make the return value self-documenting. >> >> An associative array would combine the worst of an array (no IDE >> autocompletion, no strong typing, increased memory usage) with the worst of >> an object (no easy way to extract the values into local variables with array >> destructuring). >> >> The example in the RFC doesn't show it, but the following makes the proposed >> API really convenient to use: >> >> $slicesOfPizza = new BcMath\Number(8); >> $mouthsToFeed = new BcMath\Number(3); >> [$perMouth, $slicesLeft] = $slicesOfPizza->divmod($mouthsToFeed); >> >> Note how the order of values matches the words in the method name. First the >> result of 'div', then the result of 'mod’. > > > Thanks, I have added this example to the RFC (Please let me know if you > have any problems). > > >> I came here to say the same thing. The best solution would be not having to >> refer to documentation or experiment with values, and this hits the nail on >> the head. >> >> The only thing that makes it weird is having to write it out, which at that >> point, it is probably faster to type out bcdiv and bcmod separately. >> >> 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 > PHP tends to avoid such implementations, so we didn't adopt it. The > 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-ref 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-performance hit it is, you won't notice. 99% of the time I believe that is the correct approach. I can see the argument that this is the other 1%, since it's just two values, 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 documentation *always* use examples that return into a `[$foo, $bar]` destructured list. Don't even suggest that people should use 0 and 1 indexes. 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 possible, lest we lead people down the dark path. (Which means removing the current index-using example and just keeping the pizza example.) --Larry Garfield
