|
in reply to Re^3: How does Math::GMP overload the assignment operator ?
in thread How does Math::GMP overload the assignment operator ?
There's no denying that being able to do $clone = $orig is very convenient if you both understand the limitations, and make sure you work around them.
It's quicker to type, and also easier to remember, than $clone = $orig->gmp_copy()
But, as an author who has enabled this convenience in his modules, is it acceptable that I don't document the traps that users might fall into when they avail themselves of this option ?
With Math::GMP (which I've neither authored or maintained), I initially considered it smart of them to not explicitly overload '=', and to also not mention that this option exists.
I thought that, in doing this, they were taking advantage of the fact that there's no onus upon them to document anything at all about this option.
And I also thought that I might take the same path with my modules.
However, I'm no longer so sure about the validity of that thinking - and I think, in my modules, I will make some brief mention of the traps, along with a recommendation to read the overload documentation carefully.
It occurs to me that, if one wanted to code defensively, doing $clone = $orig + 0 is safer than doing $clone = $orig.
Cheers,
Rob |
Re^5: How does Math::GMP overload the assignment operator ?
by Haarg (Priest) on Nov 09, 2020 at 03:38 UTC
|
The real solution to this is to make your objects immutable. Don't provide any methods that change the value of your object, and instead return new objects. You could then remove your += and similar overloads and = overload, and just rely on creating new objects from your + overload.
It would actually be possible to still provide the += overload as an optimization if you were providing the = overload. Since the only way to trigger mutation of the object would be via the overload, perl would protect you from ever modifying a shared object by cloning using the = overload. I'm not sure that the extra complexity here would really be worth it.
| [reply] |
|
|
The real solution to this is to make your objects immutable
That (along with the elaboration you've provided) seems to be describing exactly what Math::GMP does.
And yet Math::GMP also sets that very same troublesome trap wrt overloading '=' that I find disconcerting.
So, I'm left wondering just what it is that this "solution" solves.
I'll point out that I don't mean that last sentence to sound as smartarsey as it does. Deep down I know the problem is that I'm being dense.
Cheers,
Rob
| [reply] |
|
|
| [reply] |
|
|
|
|
| [reply]
[d/l] |
|
|
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] |
|
|
|
|
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] |
|
|
|
|
