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

The only thing it does different from what I would have naively done before I read its source code is to call CORE::require instead of require. But such streaks of paranoia are only necessary in a world where people do things like putting code in UNIVERSAL, so... :-)

PS: Yes, I know it does that not out of paranoia but rather out of having a sub named "require" in it's own namespace. I was joking.

Replies are listed 'Best First'.
Re^5: Gracefully choosing which module to use
by nothingmuch (Priest) on Jun 14, 2005 at 14:38 UTC
    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
      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.