Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: (Ovid) Re(2): ref, no, maybe?

by merlyn (Sage)
on Jan 11, 2001 at 05:22 UTC ( [id://51048] : note . print w/replies, xml ) Need Help??

in reply to (Ovid) Re(2): ref, no, maybe?
in thread ref, no, maybe?

My gut level feel is that being overly flexible on input parameters is often a sign of premature optimization. And yes, a "ref" in the code means you're looking in the mirror just a little too hard, most often. There are clearly valid uses for ref, but the first reaction I always have is "can we simplify this", and as you discovered, you could.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re (tilly) 4: ref, no, maybe?
by tilly (Archbishop) on Jan 11, 2001 at 05:54 UTC
    How can I say strongly enough that this subtle point strikes directly at my gut feeling about clean design? If you are trying to overload a design or make it magic then it is trying to do too much and needs to be rethought!

    It may take some attention and focus to see what Randal is talking about here, but the point came up several times in the Re (tilly) 1: Supersplit thread. Basically making things magic makes them more complex to implement and harder to learn. Remember that the most complex bugs to track down are at your interfaces and think twice before making those interfaces needlessly difficult to figure out.

    Sometimes it is worth breaking this rule, but (like most rules) not without specific good reason.