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 | [reply] [Watch: Dir/Any] [d/l] [select] |
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] [Watch: Dir/Any] |
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] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] [d/l] |
Operator overloading make objects behave like primitive types, and you wouldn't use 3->clone() or "abc"->clone()
| [reply] [Watch: Dir/Any] [d/l] [select] |