Re: disambiguating require (or: require loves join more than catfile)

Are you ~sure~ this does what you want it to? Require behaves differently if you feed it a bareword or a variable. (Maybe this was the reason for catfile?)

http://perldoc.perl.org/functions/require.html

use strict;
use warnings;

my $x="x";
my $module = $x . '::' . $x;

print "$module\n";
eval { require $module; };
[download]

The eval block needs some finetuning to actually do what you want it to. (Do something if require succeeds, do something else if require fails. Recommendation: Use Try::Tiny and stop worrying about all the ways eval / $! / $_ can go wrong.

use strict;
use warnings;

use Try::Tiny;

my $x="x";
my $module = $x . '::' . $x;

try {
  require $module;
  print "Found module $module.\n";
}
catch {
  print "Failed to find module $module!\n";
};
[download]

Comment on Re: disambiguating require (or: require loves join more than catfile) Select or Download Code

Replies are listed 'Best First'.
Re^2: disambiguating require (or: require loves join more than catfile) by rovf (Priest) on Jul 23, 2013 at 15:37 UTC
Are you ~sure~ this does what you want it to? I think so. I have the absolute path to a file containing a set of functions which I want to drag into my code, and this should happen at runtime. If there is a problem with the 'required' file, it's fine for me to get an exception. I could catch it, but in my particular case I just want to abort the program, so the default behaviour is fine. -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]
Re^3: disambiguating require (or: require loves join more than catfile) by Monk::Thomas (Friar) on Jul 24, 2013 at 07:36 UTC
Ah. Then another question: Do you expect this code to run on multiple platforms? (I'm asking because you used catfile.) In that case I'd recommend using Path::Class in favor of File::Spec because The well-known module File::Spec also provides this service, but it's sort of awkward to use well, so people sometimes avoid it, or use it in a way that won't actually work properly on platforms significantly different than the ones they've tested their code on. In fact, Path::Class uses File::Spec internally, wrapping all the unsightly details so you can concentrate on your application code. Whereas File::Spec provides functions for some common path manipulations, Path::Class provides an object-oriented model of the world of path specifications and their underlying semantics. File::Spec doesn't create any objects, and its classes represent the different ways in which paths must be manipulated on various platforms (not a very intuitive concept). Path::Class creates objects representing files and directories, and provides methods that relate them to each other. -- from http://search.cpan.org/~kwilliams/Path-Class-0.32/README.pod Recommended reading: http://www.perladvent.org/2012/2012-12-01.html	[reply]