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.

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.