It would be nice if you could provide a simple example for the uninitiated
The problem was raised back in11123482.
It's essentially demonstrated by the fact that the following 2 demos do different things - which means that one of them doesn't DWIM.
use Math::GMP;
$orig = Math::GMP->new(5);
$copy = $orig;
$copy += 4; # $copy is 9
# $orig is 4
VERSUS:
use Math::GMP;
$orig = Math::GMP->new(5);
$copy = $orig;
$copy->add_ui_gmp(4); # $copy is 9
# $orig is 9
Haarg was saying that you avoid this issue by not providing the add_ui_gmp() method in the first place.
It's not needed because you can simply use the operator overloading (as per the first example) to achieve the result you want.
Furthermore, you would not provide every other method that offers in-place altering of values - thereby forcing the user to utilize the (existing) operator overloading that performs the same task.
This approach requires that all of the operator overloading returns a new object.
There's one little caveat here that's easy to work around.
With floating point objects (eg. Math::BigFloat and Math::MPFR), values can be altered by changing the precision of the object, but you probably don't have an overloaded operator that you can use to do that.
Therefore, you need to have a function that provides that capability.
But that's ok. You just have to make sure that this function returns a new object, rather than simply modifying an existing one.
(This was the exact issue that led to the Math::MPFR bug report I also mentioned.)
Cheers,
Rob | [reply]
[d/l]
[select] |
| [reply]
[d/l] |
I didn't propose a solution to "everything". I proposed a solution to the specific problem being discussed.
You can't accidentally modify a shared object if you can't modify the object at all. I'm not sure what else there is to explain.
| [reply] |
| [reply]
[d/l] |
