If you're not doing anything to [sic] complicated, then what's wrong with the indirect object syntax, and why should it be avoided?

The biggest problem with indirect object notation is that perl has to jump through hoops to decide whether method Class; should be interpreted as Class->method() or method("Class") and small changes to the order of those hoops can make perl change its mind. That can result in the appearance of nasty hard-to-find bugs in previously working code after a small seemingly innocuous change.

When used in instance method calls, the "object" suffers from the same brittle parsing that the filehandle argument to print() does. That is, however, a relatively uncommon practice in comparison to the habit of using it for class methods, particularly constructors.

You are right that problems rarely arise in simple use. But, they do exist whether or not you are doing something complicated. That means you could be bitten when your simple code goes through several iterations and becomes more complicated or if you continue to use the syntax out of habit even when you take on a more complex project.

Look at it this way... If you get tripped up by a subtle bug caused by the finickiness of indirect object syntax, you'll likely spend an hour or more pulling out your hair trying to debug a problem that you are sure you shouldn't be seeing... And when it's all over and you've determined the cause, you'll swear an oath never to use indirect object notation again anyway.

Or, you might never run into the problem in which case you'll keep your hair as well as the bad habit and eventually you'll be hired as a PHB and stop coding altogether. But then you'll be forever furtively glancing over your shoulder in fear of the inevitable attack by a bald maintenance programmer with a strong homicidal urge brought on by debugging your code...

Why not save yourself the trouble by breaking the bad habit now? ;-)

-sauoq
"My two cents aren't worth a dime.";