in reply to Re^4: Gracefully choosing which module to use
in thread Gracefully choosing which module to use

Ah, but that is not the reason I use UNIVERSAL::require.

In an effort to optimize for readability, I try to make sure that there are no bits of code that don't make perfect sense when being read.

Ofcourse, with some lines this just can't be done, but then you use comments.

The point is that eval "require $class"; is readable, but to when I read the code eval is one of the things that usually makes me pay close attention, and if this is only loading the module in $class, It's nothing special.

Loading a module is not what the lines where it's loaded are doing, but rather to what those lines need to do whatever it is they do.

By that rationale I prefer to make that code stand out less, so that I can switch focus to the important code more quickly.

I know this might sounds a bit far fetched, but I tend to have a hard time concentrating when I'm reading, unless I'm in a very good state (happy, energized, not hungry, not thirsty, not in a rush, not too jumpy, not too distracted...

-nuffin
zz zZ Z Z #!perl

Replies are listed 'Best First'.
Re^6: Gracefully choosing which module to use
by gaal (Parson) on Jun 14, 2005 at 15:36 UTC
    I'm in complete agreement with the refactoring principle you cite.

    I guess I don't agree with the substantive call you're making in this case: something with UNIVERSAL in its name is likely to give me more pause than a simple eval. As well as seeing Module->require, which until I *know* about UNIVERSAL::require, looks (to me) like a bug.

    I'd agree with you if you said the same thing about SUPER, though, because (mostly because I usually use superclass methods more often than funky requires) it solves a sorer problem and is thus more worth learning about.

    Hey, you can always create a "require_module" method. I don't expect to need such a method in more than one place per project.