in reply to Things I Don't Use in Perl

Similar to the original post, another thing I never use is overloaded operators. (In any language.) More generally I don't like anything which changes the syntax, or "basic meaning" of a language. (I'm not sure which term to use here.) Tied variables fall into this category, as do lvalues.

Basically I want a Perl hash to act like a Perl hash; if it's not exactly like a Perl hash, then it should be a SomeOtherHash object. I want an equal sign to mean the same thing anywhere I see it; if I need something else, use an is_equal_in_some_way() sub. I want a sub to be a sub, not something I can assign to.

It's not that there's anything inherently wrong with those things, it's that they aren't Perl, or that they change Perl in a fundamental way. It's easier to read code when we're all speaking the same language.

Better to combine existing words into meaningful phrases than to make up new words. Better to make up new words than to change the meaning of words I already understand to mean something else. "From now on, 'green' means 'tired'. I sure am green today!" That's very confusing to me.

Replies are listed 'Best First'.
Re^2: Things I Don't Use in Perl
by itub (Priest) on Aug 23, 2005 at 17:15 UTC
    I find overloaded operators very useful in the limited context of mathematical objects such as vectors and matrices. They can make these kinds of formulas more legible IMHO: I'd rather have 
    $z = $x x $y / ($x . $y)

    [download]
    than 
    $z = $x->cross($y)->divide_by($x->dot($y));

    [download]
    (See the Math::VectorReal module, for example).
[reply]
[d/l]
[select]
      It definitely makes the equation easier to read, but I'm not sure if it makes the code easier to read. You can't easily tell that "." may be doing tons of matrix operations (or who knows what else), not concatenating some strings. It looks like standard Perl, but it's not really Perl, it's mathematics. But on the other hand, people may already have a strong preconception of what "." means with regards to matrix manipulation. And it's easier/faster to type. I can see your point.
[reply]
        It's all in the context. If that line of code is part of a vector algebra program, in a subroutine called "rotate_vector", and the names of the variables suggest that they might be vectors, it should be pretty obvious what the dot means. ;-) But yep, in some other context it might be confusing.
[reply]
      The only reason you find those overloaded operators useful in the context of mathematics is that, in general, those symbols have already been overloaded as part of the standard mathematical notational. You're just conforming with a pre-existing convention; and convention is the only reason that such overloading appears natural to you.

      For coding, I prefer to conform to the larger convention: I don't redefine symbols, because I don't need to redefine symbols, and the small gain I get from standardization with a localized mathematical convention is washed out by the big loss in standardization for general coding conventions.

      I guess I don't like code that reads: 

      $x = $y + $z; # delete all files if running as user wilbur

      [download]

      which is exactly what operator overloading allows. Specifically, it removes any guarantees that I once had about what is being done to what, when. Instead, every single line is suspect, and must be read in a much wider context to verify correctness, which I see as a huge loss for maintainability.

      Sooner or later, someone will make a deliberate or accidental piece of malicious code, and the easier it is to track it down, the better.

[reply]
[d/l]
        I guess I don't like code that reads: 
        $x = $y + $z; # delete all files if running as user wilbur

        [download]
         Bad names are bad names whether they are overloaded or not. If you can't trust your programmer to choose sensible times to overload an operator, why would you trust him in selecting subroutine names at all? 
        $x = fluffy_bunnies_are_cute($y,$z); # delete all files

        [download]
[reply]
[d/l]
[select]
Re^2: Things I Don't Use in Perl
by dragonchild (Archbishop) on Sep 28, 2005 at 13:48 UTC
    I was actually thinking about this, recently. I've discovered that I primarily use overload to overload numify, stringify, and boolify in order to have objects that behave as expected when used in other situations. For example, a Null object.

    I tend to avoid overloading the mathematical operators because the behavior tends to not be well-thought out when it comes to two different unrelated overloaded classes that should both behave as standard numbers.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Meditations