http://www.perlmonks.org?node_id=11123515


in reply to Re^4: How does Math::GMP overload the assignment operator ?
in thread How does Math::GMP overload the assignment operator ?

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.

Replies are listed 'Best First'.
Re^6: How does Math::GMP overload the assignment operator ?
by syphilis (Archbishop) on Nov 09, 2020 at 13:52 UTC
    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

      It's not immutable. It provides an add_ui_gmp method that mutates the object. If it was actually immutable, there wouldn't be any trap because it wouldn't really matter if you cloned objects or not when using them in multiple places.

        It's not immutable. It provides an add_ui_gmp method ...

        Aaah - when I saw "methods" in your earlier post I was thinking that you meant "ways of overloading" ... but, of course, when you said "methods" you meant "methods".
        Your post makes perfect sense. (Did I mention that I might have had an inkling that I was being dense ? ;-)

        It's an interesting idea and thanks muchly for presenting it.
        However, for my own modules, I think I'll be sticking with the functions that permit objects to mutate.
        Creating new objects all of the time sounds expensive ... though I haven't done any tests on the costs.

        Cheers,
        Rob
Re^6: How does Math::GMP overload the assignment operator ?
by karlgoethebier (Abbot) on Nov 10, 2020 at 16:55 UTC
    «The real solution»

    Yet another ToE or another Promised Land? It would be nice if you could provide a simple example for the uninitiated. No kidding. Best regards.

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      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

        Thanks for advice. Best regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      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.

        Thanks for advice. I begin to see it clearly now. Regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help