Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Not a fan of this change. What's wrong with saying $foo->require or die $@; That's not too much to type. It breaks this kind of useful idiom: $this->require or $that->require or die "No alternatives found: $@"; and it breaks this kind of portability even more

    if ( $better->require )
    {
       $better->frobnicate;
    }
    else
    {
        $default->frobnicate;
    }
    It also makes it difficult to write a custom error message - I have to wrap the call in an eval, and so we're back where we started before UNIVERSAL::require.

    require() has 2 modes - success or failure. It's only trying to do one thing - load code. It seems reasonable to differentiate these cases by returning true or false, rather than returning true or die. Might as well not return the true value if the failure mode will die anyway.

    You'll save a few people who are not in the habit of checking return values from tripping over their feet. The rest of us will have to start wrapping these calls in evals if we want to take alternative action when a particular module doesn't load.

    d.

    • I have to wrap the call in an eval, and so we're back where we started before UNIVERSAL::require.

      No we're not. Now you're wrapping it in eval{}, not in eval "". That's a big win.
      --
      rjbs
      • Coincidentaly, this is what Module::Load does -- analogous to 'require', but not doing the silly bareword vs string differentiation:

        use Module::Load;

        my $module = 'Data:Dumper';
        load Data::Dumper; # loads that module
        load 'Data::Dumper'; # ditto
        load $module # tritto


        You can read the docs here [cpan.org]
      • I'd argue that's a small win. We're talking about a single call, like eval { $fooo->require }. The only win here is if we declared $foo, not $fooo. eval { $foo->reqiure } is still a runtime error.
    • What's wrong with saying $foo->require or die $@; That's not too much to type.

      Its not about the amount of typing (well... part of it is). Its about the expectation that require() should die. Even *I'm* surprised to find out that $foo->require doesn't die and I WROTE THE MODULE!

      Error checking should be something you turn off, not something you turn on. Especially when it comes to dealing with the World Outside Your Program. Files, networks, etc... things not totally under your program's control a