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

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com
Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Sunday October 02, 2005
03:04 AM

UNIVERSAL::require must die!

[ #26966 ]

Here I am preparing a new release of UNIVERSAL::require and I just can't
document that the right thing to do is:

                $module->require or die $UNIVERSAL::require::ERROR;

Yuck. So early in the module's development and already the interface is
fucked. Not only is that a lot to type, a lot of people don't realize
UNIVERSAL::require does not die. And why should they? require() dies.
UNIVERSAL::require should die.

I'd rather fix it now than never be able to. Here's the plan.

-1) UNIVERSAL::require is getting its own distribution separate from
          UNIVERSAL::exports both to highlight the module better and to avoid
          any upgrade pain around UNIVERSAL::require from effecting
          UNIVERSAL::exports.

0) I've looked through the modules using UNIVERSAL::require (cpansearch++)
        and noticed only a few cases where the code wasn't dying on failure.
        So the potential impact of changing require() to die is small.

1) Add use() which will be just like require() except...
                * It calls import()
                * It dies on failure to load.

2) Add require_or_die() which is just like require() except...
                * It dies on failure to load.

3) Email all known users of UNIVERSAL::require (CPANTS++, cpansearch++) and
        telling them to switch to require_or_die() or use() and bump up their
        required version to 0.04.

4) Declare that the behavior of require() will change in the future to
        match require_on_die() unless there's a storm of protest.

That gives folks an upgrade path and enough lead time to adjust their code
to the change.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

UNIVERSAL::require must die! 20 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • So this: ../JFDI/lib/JFDI/Web.pm: unless ($class->require) { will stop working in the future? About 40% of our internal code that uses UNIVERSAL::require is dying on failure. But that leaves 60% that isn't. And having something so simple change semantics out from under us is going to lead to pain. That makes me sad. Please do note that there's a lot of code out there that uses CPAN modules but isn't on CPAN itself. Maybe someday we'll get a sane module versioning system ;)

    • unless ($class->require) { will stop working in the future?

      That's the plan.

      Please do note that there's a lot of code out there that uses CPAN modules but isn't on CPAN itself.

      If you look at the Makefile.PL for UNIVERSAL::require [cpan.org] you'll notice logic in there which checks if the currently installed version of the module is older than the last API change. If so, it warns about the API change and sleeps for a moment so there's a hope of it being seen. Additionally, I'll put this warning in the version

      • But that still breaks existing code. What about having the "...and die" behaviour require a different "use UNIVERSAL::require" line?
        • Already thought about this.

          package A;
           
          use UNIVERSAL::require;
           
          package B;
           
          use UNIVERSAL::require qw(die);
           
          package C;
           
          Some::Module::Which::Does::Not::Exist->require;

          What happens? Thus is the curse of UNIVERSAL. I also can't use a different package name, such as UNIVERSAL::use or UNIVERSAL::load, if its going to have a require() method because then UNIVERSAL::require and UNIVERSAL::use could not be used together in the same package.

          • because then UNIVERSAL::require and UNIVERSAL::use could not be used together in the same package.
            s/package/program/

  • 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 starte

    • 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

  • all known users of UNIVERSAL::require (CPANTS++, cpansearch++)

    Er... are you assuming that all users of UNIVERSAL::require have their code on CPAN? :-)
    • Er... are you assuming that all users of UNIVERSAL::require have their code on CPAN? :-)
      Yet Another Reason to Release to CPAN. ( YARRC?) You get early notice when a module you rely upon is changed.
      • True, but sometimes... you just can't :-)
      • Are you kidding?

        You want us to drop every silly web application we've ever written for every client into CPAN?

        Stuff that contains business logic that only applies to a guava farmer working in the north-western tasmania local government area of Tasman, who uses Quickbooks and has Internet Explorer specific functionality?
    • Er... are you assuming that all users of UNIVERSAL::require have their code on CPAN? :-)
      No, just all known users. Look inside the Makefile.PL for how everyone else is informed.
      • Hum, that is a good idea. However, shouldn't it ask "Do you want to install this thing, because it might screw things up?" instead of just saying "Hey, watch out, because you might just have screwed things up..." (I'm thinking automated instalations here)

        I might be getting something wrong, though, and I'm not sure whether you'd be able to prevent the instalation from within Makefile.PL. Probably.
        • You're right, I should ask the user using prompt(). I'd probably have it default to "Yes" most of the time as it would be far too obnoxious for someone to fire off an automated install and then have it fail halfway through because I made some trivial backwards incompatibility. Though if I was to have made the require change I'd have it default to "no".

          I might be getting something wrong, though, and I'm not sure whether you'd be able to prevent the instalation from within Makefile.PL. Probably.

          There is t

          • There's another issue... you're checking whether the module is already available and deciding whether the guy is using it depending on it being instaled before... what if he used it before, but is now installing things on a brand new machine? :-\

            There is the simple expedient of just not producing a Makefile.

            Indeed :-)

            • There's another issue... you're checking whether the module is already available and deciding whether the guy is using it depending on it being instaled before... what if he used it before, but is now installing things on a brand new machine?

              In that case then its being installed as a dependency of something which itself has not yet been installed. When the dependent thing gets installed its own tests will run and detect if the incompatibility caused a problem.

              Oh... you do have tests, right?

              • Right, but maybe printing out a notice explaining what's happening would help, in that case (telling the user that maybe installing a previous version would solve the problem).

                That, however, poses a problem, as the module was already installed... but maybe you can somehow detect, er... something else O:-)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.