Thanks all, > My only question is the pseudo-tuple return, which is rarely used in PHP > (although I've used it myself, I think exactly once), and I think this would > be the first use of it in a built in library. (I may be wrong on that.) I > don't have a particular alternative to suggest, just flagging that as the > main part that could warrant discussion.
> It's actually already used by gmp_div_qr(), so +1 from me. I predicted this would probably be on the agenda. Another idea is to pass arguments by reference, like in `exec()`. Personally, I find something like a tuple easier to use. However, without generics, all we know is that the return type is an array, which may be inconvenient in terms of IDE completion, etc. > I'm wondering whether this needs to be a change to the API, or if it might be > better implemented as a purely internal optimisation to BCMath / Number - in > some way memoize both the quotient and the remainder when either div or mod > is called, and then document for users that calling one after the other will > be extremely cheap to run. > > But maybe that brings up too many questions about memory usage - e.g. is the > memory for this reserved in advance for each instance of Number, or allocated > when one of these functions is called, and should it be freed even while the > object remains in scope to avoid using lots of memory if many numbers are > divided or modded. I am considering implementing this not only as a Number class, but also as a function. Also, it is not practical to record the remainder in the Number object resulting from the division. This is because there can be objects whose division results are equal but whose remainders are different. In the discussion of the Number class, it was argued that objects should not have too much state. Increasing the state of surplus is not desirable in this respect, as it contradicts the previous argument. Regards, Saki
