FAQ
Does anyone know the reason behind require($foo) only working when $foo
has already got slashes and ".pm" on the end?

i.e.:

require IO::Socket; # works
$var = "IO::Socket"; require $var; # fails
$var = "IO/Socket.pm"; require $var; # works

It looks like it would be trivial to patch Perl_ck_require to support the
second line there, but I guess it would probably break somebody's backward
compatibility. If it wouldn't, I can supply a patch. But mostly I just
want to know what the reasoning is behind this strange behaviour.

--
<!-- Matt -->
<:->Get a smart net</:->

Search Discussions

  • Rafael Garcia-Suarez at Nov 19, 2002 at 12:04 pm

    Matt Sergeant wrote:
    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?

    i.e.:

    require IO::Socket; # works
    $var = "IO::Socket"; require $var; # fails
    $var = "IO/Socket.pm"; require $var; # works

    It looks like it would be trivial to patch Perl_ck_require to support the
    second line there, but I guess it would probably break somebody's backward
    compatibility. If it wouldn't, I can supply a patch. But mostly I just
    want to know what the reasoning is behind this strange behaviour.
    Alternatively you can roll your own module around this :

    BEGIN {
    *CORE::GLOBAL::require = sub {
    my $f = shift;
    eval { require $f };
    if ($@) {
    $f =~ s,::,/,g;
    $f .= '.pm';
    require $f;
    }
    };
    }
    require "IO::Socket";
    print "$_\n" for keys %INC;

    Alternatively this could even be implemented as a pragma.
  • Matt Sergeant at Nov 19, 2002 at 12:58 pm

    On Tue, 19 Nov 2002, Rafael Garcia-Suarez wrote:

    Alternatively you can roll your own module around this :
    I'm quite aware of the multitude of ways around this. That was not the
    question I asked though :-)

    --
    <!-- Matt -->
    <:->Get a smart net</:->
  • Tim Bunce at Nov 19, 2002 at 2:48 pm

    On Tue, Nov 19, 2002 at 11:03:53AM +0000, Matt Sergeant wrote:
    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?

    i.e.:

    require IO::Socket; # works
    $var = "IO::Socket"; require $var; # fails
    $var = "IO/Socket.pm"; require $var; # works

    It looks like it would be trivial to patch Perl_ck_require to support the
    second line there, but I guess it would probably break somebody's backward
    compatibility. If it wouldn't, I can supply a patch. But mostly I just
    want to know what the reasoning is behind this strange behaviour.
    The first form uses the 'logical' form of the class name,
    the third uses the physical form. They are distinct.

    The first form also adds the class name to the symbol table.

    Perl uses "/" as its internal cannonical directory separator
    irrespective of the underlying OS. (Mac OS uses ":" and that
    may cause problems.)

    I'd argue for the status quo. I don't think anything is broken.

    Tim.
  • Rafael Garcia-Suarez at Nov 19, 2002 at 3:11 pm

    Tim Bunce wrote:
    On Tue, Nov 19, 2002 at 11:03:53AM +0000, Matt Sergeant wrote:
    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?

    i.e.:

    require IO::Socket; # works
    $var = "IO::Socket"; require $var; # fails
    $var = "IO/Socket.pm"; require $var; # works

    It looks like it would be trivial to patch Perl_ck_require to support the
    Sorry, just saw that you said _ck_ and not _pp_.
    By patching Perl_ck_require you could support
    require "IO::Socket";
    (just remove the OPpCONST_BARE check or something)
    but probably not
    $var = "IO::Socket"; require $var;
    second line there, but I guess it would probably break somebody's backward
    compatibility. If it wouldn't, I can supply a patch. But mostly I just
    want to know what the reasoning is behind this strange behaviour.
    The first form uses the 'logical' form of the class name,
    the third uses the physical form. They are distinct.

    The first form also adds the class name to the symbol table.
    AFAIK there isn't any runtime behavior change between the two forms.
    Looking inside :

    $ perl -MO=Concise -e 'require IO::Socket'
    5 <@> leave[t1] vKP/REFC ->(end)
    1 <0> enter ->2
    2 <;> nextstate(main 1 -e:1) v ->3
    4 <1> require sK/1 ->5
    3 <$> const(PV "IO/Socket.pm") s/BARE ->4

    The string constant has been translated at compile time (although
    it's still marked as a bareword).
    Perl uses "/" as its internal cannonical directory separator
    irrespective of the underlying OS. (Mac OS uses ":" and that
    may cause problems.)

    I'd argue for the status quo. I don't think anything is broken.
    I share this opinion.
  • Matt Sergeant at Nov 19, 2002 at 3:50 pm

    On Tue, 19 Nov 2002, Tim Bunce wrote:
    On Tue, Nov 19, 2002 at 11:03:53AM +0000, Matt Sergeant wrote:
    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?

    i.e.:

    require IO::Socket; # works
    $var = "IO::Socket"; require $var; # fails
    $var = "IO/Socket.pm"; require $var; # works

    It looks like it would be trivial to patch Perl_ck_require to support the
    second line there, but I guess it would probably break somebody's backward
    compatibility. If it wouldn't, I can supply a patch. But mostly I just
    want to know what the reasoning is behind this strange behaviour.
    The first form uses the 'logical' form of the class name,
    the third uses the physical form. They are distinct.

    The first form also adds the class name to the symbol table.
    I don't think that's too relevant to this situation though.
    Perl uses "/" as its internal cannonical directory separator
    irrespective of the underlying OS. (Mac OS uses ":" and that
    may cause problems.)
    This I knew - I have lots of code that does this, and I was just adding it
    to Yet Another Project. And I started to question why I had to do this?
    Why can't perl just DWIM?
    I'd argue for the status quo. I don't think anything is broken.
    I agree with the sentiment. Nothing is "broken", and I wasn't suggesting
    "fixing" anything. It's a potential enhancement, to make life easier.

    Oh no. I am now picturing myself in one of MJD's talks... Next someone
    will mention syntax ;-)

    --
    <!-- Matt -->
    <:->Get a smart net</:->
  • Jan Dubois at Nov 19, 2002 at 4:52 pm

    On Tue, 19 Nov 2002 11:03:53 +0000 (GMT), Matt Sergeant wrote:

    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?

    i.e.:

    require IO::Socket; # works
    $var = "IO::Socket"; require $var; # fails
    $var = "IO/Socket.pm"; require $var; # works

    It looks like it would be trivial to patch Perl_ck_require to support the
    second line there, but I guess it would probably break somebody's backward
    compatibility. If it wouldn't, I can supply a patch. But mostly I just
    want to know what the reasoning is behind this strange behaviour.
    How would you define the semantics though?

    require "IO::Socket";

    can probably be turned into

    require "IO/Socket.pm";

    without too many compatibility problems. But

    require "Foo";

    must *not* be turned into

    require "Foo.pm";

    but should return an error that the *file* "Foo" has not been found:

    Can't locate Foo in @INC

    and not

    Can't locate Foo.pm in @INC

    So you would have to search through all of @INC for "Foo" first, and if
    that fails, retry it for "Foo.pm", and if that still fails, report that
    "Foo" is not found? Sounds like a bad idea to me. And only applying your
    DWIMery on strings containing "::" seems inconsistent.

    I think the current implementation is just fine. :)

    Cheers,
    -Jan
  • Matt Sergeant at Nov 19, 2002 at 5:15 pm

    On Tue, 19 Nov 2002, Jan Dubois wrote:

    On Tue, 19 Nov 2002 11:03:53 +0000 (GMT), Matt Sergeant
    wrote:
    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?
    How would you define the semantics though?

    require "IO::Socket";

    can probably be turned into

    require "IO/Socket.pm";

    without too many compatibility problems. But

    require "Foo";

    must *not* be turned into

    require "Foo.pm";

    but should return an error that the *file* "Foo" has not been found
    Thanks Jan, that was the explanation I was looking for :-)

    Here's hoping perl6 doesn't make us go through this chicanery to load a
    module from a variable.

    --
    <!-- Matt -->
    <:->Get a smart net</:->
  • Michael G Schwern at Nov 19, 2002 at 11:18 pm

    On Tue, Nov 19, 2002 at 11:03:53AM +0000, Matt Sergeant wrote:
    Does anyone know the reason behind require($foo) only working when $foo
    has already got slashes and ".pm" on the end?
    I don't know the historical reason, but here's one I can think of:

    $ cat Foo\:\:Bar
    print "Required the file Foo::Bar\n";
    1;

    $ perl -wle 'require "Foo::Bar"'
    Required the file Foo::Bar

    You don't want introduce the caveat where you can't require a file in @INC
    because it happens to match the regex /^\w+(::\w+)+$/


    You could try something like this:

    If -e $file then
    load $file
    else if $file =~ /^\w+(::\w+)$/
    $file =~ s{::}{/}g;
    $file .= '.pm';
    load $file

    ie. check to see if a file by the literal name already exists, if so load
    it. Otherwise try it as a module. But it reverses the problem (the module
    Foo::Bar now masks the file Foo::Bar) and introduces ambiguity.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    "Please hold while reality is adjusted to match my ideal world."
    -- njt
  • Matt Sergeant at Nov 20, 2002 at 9:03 am

    On Tuesday, Nov 19, 2002, at 23:17 Europe/London, Michael G Schwern wrote:
    On Tue, Nov 19, 2002 at 11:03:53AM +0000, Matt Sergeant wrote:
    Does anyone know the reason behind require($foo) only working when
    $foo
    has already got slashes and ".pm" on the end?
    I don't know the historical reason, but here's one I can think of:

    $ cat Foo\:\:Bar
    print "Required the file Foo::Bar\n";
    1;

    $ perl -wle 'require "Foo::Bar"'
    Required the file Foo::Bar
    I guess then the real question is why does require() have this
    duplicate behaviour? It seems to me that require EXPR is exactly
    equivalent to:

    unless($INC{$file}) {
    do($file) or die "$!$@";
    }

    But at least now I know this change would break something somewhere.
    What we really need is a re-vamped perl. Yeah, a new version! We could
    call it perl6! :-)

    Matt.
  • Michael G Schwern at Nov 20, 2002 at 9:38 am

    On Wed, Nov 20, 2002 at 09:04:06AM +0000, Matt Sergeant wrote:
    $ cat Foo\:\:Bar
    print "Required the file Foo::Bar\n";
    1;

    $ perl -wle 'require "Foo::Bar"'
    Required the file Foo::Bar
    I guess then the real question is why does require() have this
    duplicate behaviour?
    So we can load modules by their module name instead of by their filename?
    Or do you mean why cram it into require()?

    It seems to me that require EXPR is exactly
    equivalent to:

    unless($INC{$file}) {
    do($file) or die "$!$@";
    }
    Fun fact! When $file is just a filename require checks through @INC for
    that file. If $file contains any directory information then its the above.

    require "foo.pl"; # check @INC for foo.pl
    require "./foo.pl"; # only check the cwd for foo.pl

    But at least now I know this change would break something somewhere.
    What we really need is a re-vamped perl. Yeah, a new version! We could
    call it perl6! :-)
    I quite like the Some::Module->require syntax UNIVERSAL::require gives you
    rather than magic require bareword tricks.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    We are going to do something terrible to you. We are going to deprive
    you of an enemy.
    -- Georgi Arbatov
  • Rafael Garcia-Suarez at Nov 20, 2002 at 9:51 am

    Michael G Schwern wrote:
    It seems to me that require EXPR is exactly
    equivalent to:

    unless($INC{$file}) {
    do($file) or die "$!$@";
    }
    Fun fact! When $file is just a filename require checks through @INC for
    that file. If $file contains any directory information then its the above.

    require "foo.pl"; # check @INC for foo.pl
    require "./foo.pl"; # only check the cwd for foo.pl
    do($file) checks @INC the same way than require($file).
    If the file begins with / or ./ or ../ (UNIX-wise) then @INC isn't
    searched.
  • Matt Sergeant at Nov 20, 2002 at 11:45 am

    On Wed, 20 Nov 2002, Michael G Schwern wrote:
    On Wed, Nov 20, 2002 at 09:04:06AM +0000, Matt Sergeant wrote:
    $ cat Foo\:\:Bar
    print "Required the file Foo::Bar\n";
    1;

    $ perl -wle 'require "Foo::Bar"'
    Required the file Foo::Bar
    I guess then the real question is why does require() have this
    duplicate behaviour?
    So we can load modules by their module name instead of by their filename?
    Or do you mean why cram it into require()?
    Why cram it into require() when do() does the job.
    It seems to me that require EXPR is exactly
    equivalent to:

    unless($INC{$file}) {
    do($file) or die "$!$@";
    }
    Fun fact! When $file is just a filename require checks through @INC for
    that file. If $file contains any directory information then its the above.

    require "foo.pl"; # check @INC for foo.pl
    require "./foo.pl"; # only check the cwd for foo.pl
    So does do(). Hence why I posted :-)
    But at least now I know this change would break something somewhere.
    What we really need is a re-vamped perl. Yeah, a new version! We could
    call it perl6! :-)
    I quite like the Some::Module->require syntax UNIVERSAL::require gives you
    rather than magic require bareword tricks.
    Yes, that's a pretty good plan, and works for scalars too. I wonder if
    there's any chance to get that into perl 5.10 :-)

    --
    <!-- Matt -->
    <:->Get a smart net</:->
  • Rafael Garcia-Suarez at Nov 20, 2002 at 12:27 pm

    Matt Sergeant wrote:
    But at least now I know this change would break something somewhere.
    What we really need is a re-vamped perl. Yeah, a new version! We could
    call it perl6! :-)
    I quite like the Some::Module->require syntax UNIVERSAL::require gives you
    rather than magic require bareword tricks.
    Yes, that's a pretty good plan, and works for scalars too. I wonder if
    there's any chance to get that into perl 5.10 :-)
    If you permit Some::Module->require then "require Some::Module" becomes
    an indirect object notation. So the bareword trick is still there as
    "require 'Some::Module'" will not change.

    What does this syntax mean ? When Some::Module is not loaded, I guess it
    means "require Some::Module". But when it's already loaded, it will call
    the require() class method on it. So for consistency it should also call
    Some::Module->require() just after it's loaded.

    As usual, there's a backward compatibility problem, when there are
    functions called "require" in a module.

    Thus you can override the "require Foo" syntax without going through the
    usual overriding mechanism. What happens when you've overriden require
    (via CORE::GLOBAL:: or via an usual import) and when you've overloaded
    UNIVERSAL::require as well ? Which one takes the precedence ?
  • Michael G Schwern at Nov 20, 2002 at 9:53 pm

    On Wed, Nov 20, 2002 at 01:23:37PM +0100, Rafael Garcia-Suarez wrote:
    I quite like the Some::Module->require syntax UNIVERSAL::require gives you
    rather than magic require bareword tricks.
    Yes, that's a pretty good plan, and works for scalars too. I wonder if
    there's any chance to get that into perl 5.10 :-)
    If you permit Some::Module->require then "require Some::Module" becomes
    an indirect object notation.
    That's not how it works out. Try the module.

    $ perl -MUNIVERSAL::require -wle 'require Foo::Bar'
    Can't locate Foo/Bar.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1
    /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5
    /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl .) at -e
    line 1.

    You can tell that its not indirect object syntax because UNIVERSAL::require
    doesn't die on failure.

    So the bareword trick is still there as "require 'Some::Module'" will not
    change.
    That's ok. The problem with require BAREWORD is that it makes this sort of
    thing difficult:

    my $module = 'Foo::Bar';
    require $module;

    so you have to say "eval qq{require $module}" instead. Or you can do this:

    my $module = 'Foo::Bar';
    $module->require;

    We obviously can't eliminate require BAREWORD.

    What does this syntax mean ? When Some::Module is not loaded, I guess it
    means "require Some::Module". But when it's already loaded, it will call
    the require() class method on it. So for consistency it should also call
    Some::Module->require() just after it's loaded.
    You mean you want this:

    require UNIVERSAL::require;

    # Some::Module is not loaded
    Some::Module->require; # call UNIVERSAL::require
    # Some::Module is now loaded

    to be the equivalent to something like this:

    require UNIVERSAL::require;

    # Some::Module is not loaded
    Some::Module->require; # call UNIVERSAL::require
    # Some::Module is now loaded

    # Call their override if there is one.
    Some::Module->require if Some::Module->can("require") ne
    UNIVERSAL::require->can("require")

    in order to maintain backwards compatibilty? But that doesn't make any
    sense because without UNIVERSAL::require this:

    # Some::Module is not loaded
    Some::Module->require;

    is just an error!

    As usual, there's a backward compatibility problem, when there are
    functions called "require" in a module.
    Here's how it works out.

    use UNIVERSAL::require;
    Some::Module->require; # module not yet loaded, only option is
    # UNIVERSAL::require.
    # Without UNIVERSAL::require this would be
    # a run-time error.

    Some::Module->require; # if Some::Module happens to have a
    # require() override it will be called

    so the override is still respected once the module is loaded. Previous to
    that it would have been an error. So there's no backwards compatibility
    problem.

    There is a caveat which is that once the module is loaded its possible
    Some::Module->require might not do what it did before, but isa() and can()
    have this same caveat.

    Its probably not a good thing to have a method which potentially does two
    different things, but its also probably not a good thing to write a method
    with the same name as a core function unless its a proper override (ie.
    respects the original interface).

    To see if this is a practical concern or not, I've just scanned all the *.pm
    files on CPAN for '^\s*sub require\b' and came up with two. One is
    UNIVERSAL::require. The other is Term::ShellKit::Dev.

    Thus you can override the "require Foo" syntax without going through the
    usual overriding mechanism. What happens when you've overriden require
    (via CORE::GLOBAL::
    Since UNIVERSAL::require is simply a wrapper around require it should
    respect any override of the core function. As long as their override is
    sane things should DWIM. As currently implemented it does not respect
    CORE::GLOBAL::require because CORE::require has to be explicitly called to
    avoid internal ambiguity. but I don't think that's actually necessary... no
    its not. Ok, CORE::GLOBAL::require is now respected. I'll put it in 0.04.

    $ perl -Ilib -MUNIVERSAL::require -wle 'BEGIN { *CORE::GLOBAL::require = sub { print "My require! @_" } } Some::Module->require'
    My require! Some::Module


    or via an usual import)
    imports have local effect, so it really shouldn't interfere with an external
    method call except the usual problems of screwing up inheritence (ie.
    imported functions can now be called as methods which is usually not what
    you want).

    and when you've overloaded UNIVERSAL::require as well ?
    If two people override the same method in the same package you get a warning
    and the last override wins.

    $ perl -MUNIVERSAL::require -wle 'sub UNIVERSAL::require { 1 }'
    Subroutine UNIVERSAL::require redefined at -e line 1.

    The warning will tip you off to the conflict. Its probably best to treat it
    as a conflict rather than try to run both. Wizardly conflicts are not
    pretty.

    Given the lack of require() changes on CPAN I don't see this conflict
    happening.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    Pancakes is the better part of valor.
    http://www.goats.com/archive/971202.html
  • Benjamin Goldberg at Nov 21, 2002 at 4:00 am
    Michael G Schwern wrote:
    [snip]
    so you have to say "eval qq{require $module}" instead.
    Or you can do this:

    my $module = 'Foo::Bar';
    $module->require;
    Or you can do:

    my $module = 'Foo::Bar';
    require { $module };

    Actually, I like this better than $module->require.... it reminds
    me of eval BLOCK vs eval EXPR, or exec BLOCK LIST vs exec LIST.

    --
    my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
    .."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]
  • Michael G Schwern at Nov 21, 2002 at 5:31 am

    On Wed, Nov 20, 2002 at 11:07:56PM -0500, Benjamin Goldberg wrote:
    Michael G Schwern wrote:
    [snip]
    so you have to say "eval qq{require $module}" instead.
    Or you can do this:

    my $module = 'Foo::Bar';
    $module->require;
    Or you can do:

    my $module = 'Foo::Bar';
    require { $module };
    Replace magic syntax with more magic syntax, good idea.

    And there's the ever present problem with new syntax: if we put this in 5.10
    everyone will have to upgrade perl to use it guaranteeing it won't be safe
    to use for years. :(

    Actually, I like this better than $module->require.... it reminds
    me of eval BLOCK vs eval EXPR, or exec BLOCK LIST vs exec LIST.
    eval BLOCK vs eval EXPR isn't a terribly good argument for given they do two
    utterly different things. And I never liked the exec BLOCK LIST
    disambiguating attempt. Everywhere else blocks contain code to be iterated
    over or otherwise run repeatedly. grep, map, sort, subroutines, loops...
    And all specific cases of func BLOCK LIST use the block as filtering code.
    Now we have exec/system BLOCK LIST which works differently than everything
    else. Bleh.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    "Let's face it," said bearded Rusty Simmons, opening a can after the
    race. "This is a good excuse to drink some beer." At 10:30 in the
    morning? "Well, it's past noon in Dublin," said teammate Mike
    [Joseph] Schwern. "It's our duty."
    -- "Sure, and It's a Great Day for Irish Runners"
    Newsday, Sunday, March 20, 1988
  • Benjamin Goldberg at Nov 21, 2002 at 8:41 pm

    Michael G Schwern wrote:
    On Wed, Nov 20, 2002 at 11:07:56PM -0500, Benjamin Goldberg wrote:
    Michael G Schwern wrote:
    [snip]
    so you have to say "eval qq{require $module}" instead.
    Or you can do this:

    my $module = 'Foo::Bar';
    $module->require;
    Or you can do:

    my $module = 'Foo::Bar';
    require { $module };
    Replace magic syntax with more magic syntax, good idea.
    Ahh, except that it's *not* magic syntax -- it's perfectly ordinary
    indirect object syntax. Or at least, it should be.

    Hmm, aparently, I should have tested it before posting that message; it
    doesn't work, producing "Can't locate HASH(0x........) in @INC ..."

    I *thought* it would work; I guess not.
    And there's the ever present problem with new syntax: if we put this
    in 5.10 everyone will have to upgrade perl to use it guaranteeing it
    won't be safe to use for years. :(
    Actually, I like this better than $module->require.... it reminds
    me of eval BLOCK vs eval EXPR, or exec BLOCK LIST vs exec LIST.
    eval BLOCK vs eval EXPR isn't a terribly good argument for given they
    do two utterly different things. And I never liked the exec BLOCK
    LIST disambiguating attempt. Everywhere else blocks contain code to
    be iterated over or otherwise run repeatedly.
    Everywhere except for print BLOCK LIST, and BAREWORD BLOCK LIST, and
    $BLOCK, and @BLOCK, and %BLOCK, and *BLOCK, and $BLOCK[EXPR], and
    $BLOCK{EXPR}, and @BLOCK[EXPR], and @BLOCK{EXPR}.

    In each of these cases, BLOCK evaluates to an object of the appropriate
    type.
    grep, map, sort, subroutines, loops... And all specific cases of func
    BLOCK LIST use the block as filtering code. Now we have exec/system
    BLOCK LIST which works differently than everything else. Bleh.
    They work rather similarly to indirect object syntax.

    --
    my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
    .."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]
  • Michael G Schwern at Nov 20, 2002 at 8:56 pm

    On Wed, Nov 20, 2002 at 11:47:39AM +0000, Matt Sergeant wrote:
    I guess then the real question is why does require() have this
    duplicate behaviour?
    So we can load modules by their module name instead of by their filename?
    Or do you mean why cram it into require()?
    Why cram it into require() when do() does the job.
    require() will only load something once, do() loads it however many times
    you call it.

    $ cat foo.pl
    print "I loaded foo.pl\n";
    1;

    $ perl -wle 'do "foo.pl"; do "foo.pl"'
    I loaded foo.pl

    I loaded foo.pl

    $ perl -wle 'require "foo.pl"; require "foo.pl"'
    I loaded foo.pl


    The former behavior is what you typically want for libraries, regardless of
    the name. The latter is more for config files.

    It would be annoying to have to say:

    do 'foo.pl' unless $INC{'foo.pl'};

    rather than

    require 'foo.pl';

    Or for you C fans out there...

    $ cat foo.pl
    return 1 if $_FOO_PL;
    $_FOO_PL = 1;

    print "Loaded foo.pl\n";

    1;

    Fun fact! When $file is just a filename require checks through @INC for
    that file. If $file contains any directory information then its the above.

    require "foo.pl"; # check @INC for foo.pl
    require "./foo.pl"; # only check the cwd for foo.pl
    So does do(). Hence why I posted :-)
    Hmmm. Then the require() example implementation in perlfunc is wrong. Or
    at least redundant.

    I quite like the Some::Module->require syntax UNIVERSAL::require gives you
    rather than magic require bareword tricks.
    Yes, that's a pretty good plan, and works for scalars too. I wonder if
    there's any chance to get that into perl 5.10 :-)
    Oh Huuuuuuuuugo...


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    <mendel> ScHWeRnsChweRN sChWErN SchweRN SCHWErNSChwERnsCHwERN
    sChWErn ScHWeRn schweRn sCHWErN schWeRn scHWeRN
    SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern
    scHWerN scHWeRn scHWerN ScHwerN SChWeRN scHWeRn
    SchwERNschwERn SCHwern sCHWErN SCHWErN sChWeRn
  • Matt Sergeant at Nov 20, 2002 at 11:53 pm

    On Wednesday, Nov 20, 2002, at 20:56 Europe/London, Michael G Schwern wrote:
    On Wed, Nov 20, 2002 at 11:47:39AM +0000, Matt Sergeant wrote:
    I guess then the real question is why does require() have this
    duplicate behaviour?
    So we can load modules by their module name instead of by their
    filename?
    Or do you mean why cram it into require()?
    Why cram it into require() when do() does the job.
    require() will only load something once, do() loads it however many
    times
    you call it.
    I already showed an example of this. Keep up ;-)
    It would be annoying to have to say:

    do 'foo.pl' unless $INC{'foo.pl'};

    rather than

    require 'foo.pl';
    The corollary to my question really is how often do you require
    'foo.pl' these days, when foo.pl is a library? Not too often unless
    you're writing perl4 style. I would hope that most people who do perl
    are using .pm files for libraries. Of course I usually vastly
    over-estimate peoples perl skills ;-)

    None of this means it should change. I just wanted to explore the
    reasons.
    Fun fact! When $file is just a filename require checks through @INC
    for
    that file. If $file contains any directory information then its the
    above.

    require "foo.pl"; # check @INC for foo.pl
    require "./foo.pl"; # only check the cwd for foo.pl
    So does do(). Hence why I posted :-)
    Hmmm. Then the require() example implementation in perlfunc is wrong.
    Or
    at least redundant.
    Nah, that @INC loop is needed to set $realfilename to populate %INC
    with.

    Matt.
  • Michael G Schwern at Nov 21, 2002 at 12:53 am

    On Wed, Nov 20, 2002 at 11:53:48PM +0000, Matt Sergeant wrote:
    It would be annoying to have to say:

    do 'foo.pl' unless $INC{'foo.pl'};

    rather than

    require 'foo.pl';
    The corollary to my question really is how often do you require
    'foo.pl' these days, when foo.pl is a library? Not too often unless
    you're writing perl4 style. I would hope that most people who do perl
    are using .pm files for libraries. Of course I usually vastly
    over-estimate peoples perl skills ;-)

    None of this means it should change. I just wanted to explore the
    reasons.
    Lots and lots and lots of people still use .pl for libraries.

    And just on TMTOWTDI principles, we don't want to restrict the naming of
    libraries to only .pm.

    Basically, you need ways to load and eval a file like this:

    Load the file (for example, config files)
    Load the file only once (for arbitrarily named libraries)
    Load the file only once and translate the package name -> filename
    (for modules)

    Currently corresponding to "do EXPR", "require EXPR" and "require BAREWORD".

    Removing the "Load the file only once" option essentially means you have to
    use the .pm file naming style.

    Hmmm. Then the require() example implementation in perlfunc is wrong.
    Or
    at least redundant.
    Nah, that @INC loop is needed to set $realfilename to populate %INC
    with.
    Ahh.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    Sometimes you eat the path, sometimes the path eats you.
  • Hv at Dec 11, 2002 at 11:40 am
    Michael G Schwern wrote:
    :On Wed, Nov 20, 2002 at 11:47:39AM +0000, Matt Sergeant wrote:
    :> > I quite like the Some::Module->require syntax UNIVERSAL::require gives you
    :> > rather than magic require bareword tricks.
    :>
    :> Yes, that's a pretty good plan, and works for scalars too. I wonder if
    :> there's any chance to get that into perl 5.10 :-)
    :
    :Oh Huuuuuuuuugo...

    I like the hack, and I'll probably start using it in my daytime code, but
    I don't feel it is important enough to justify the potential breakage
    caused by putting it in UNIVERSAL - anyone AUTOLOADing a require() method
    would be broken by this, for starters.

    I'm happy to add docs showing how to do it, or possibly a module that
    would install the hack into UNIVERSAL::.

    Hugo
  • Jos I. Boumans at Nov 22, 2002 at 9:23 am

    I guess then the real question is why does require() have this duplicate
    behaviour? It seems to me that require EXPR is exactly equivalent to:

    unless($INC{$file}) {
    do($file) or die "$!$@";
    }
    so here's an idea:
    a quite simple little module called say 'load.pm' that will wrap all the
    dwim'ery you want.

    the drawback of course is that it'll be slower, since it has more
    overhead. but hey, with all the time we spent on p5p writing alternate
    ways of doing it, i think it's justified.

    an example:

    use load;

    # load Foo::Bar, the module - will break under strict subs
    load Foo::Bar;

    # load Foo::Bar, the module
    load 'Foo::Bar';

    # load blah/zot.pl, looking in @INC
    load 'blah/zot.pl';

    # load CWD/blah/zot.pl, looking in .
    load './blah/zot.pl';

    # load the file 'Foo', looking in @INC
    # failing that, load the module ('Foo.pm'), looking in @INC
    $mod = 'Foo';
    load $mod;

    and so on..

    only 3 problems i see so far:
    first you have to explicitly 'use' load.pm before you can utilize this,
    but the benefit of making it a module/pragma is we can make it work all
    the way back to perl 5.0 ! ;)

    second, the bareword problem in the first example, which would break
    under strict, which is of course bad

    third, if your input is ambiguous, it will take longer to figure out
    'what to do', and a precedence list has to be decided on (should load
    FIRST look for the module or the filename?, etc), but that is easily
    fixed by good documentation

    i'll happily write all 20 lines of this module if this is thought a good
    idea. suggestions very welcome

    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu
  • Rafael Garcia-Suarez at Nov 22, 2002 at 9:40 am

    "Jos I. Boumans" wrote:
    use load;

    # load Foo::Bar, the module - will break under strict subs
    load Foo::Bar;
    Use prototypes :

    $ perl -Mstrict -le 'sub load(*){print"(@_)"}load Foo::Bar'
    (Foo::Bar)
    $ perl -Mstrict -le 'sub load(*){print"(@_)"}load"Foo::Bar"'
    (Foo::Bar)
  • Jos I. Boumans at Nov 22, 2002 at 10:11 am

    Rafael Garcia-Suarez wrote:
    "Jos I. Boumans" wrote:
    use load;

    # load Foo::Bar, the module - will break under strict subs
    load Foo::Bar;

    Use prototypes :

    $ perl -Mstrict -le 'sub load(*){print"(@_)"}load Foo::Bar'
    (Foo::Bar)
    $ perl -Mstrict -le 'sub load(*){print"(@_)"}load"Foo::Bar"'
    (Foo::Bar)
    *slaps forehead*
    yes...

    i'll see if i can write up a first draft for load today then


    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu
  • Jos I. Boumans at Nov 24, 2002 at 5:56 pm

    Jos I. Boumans wrote:
    i'll see if i can write up a first draft for load today then
    The uploaded file

    load-0.01.tar.gz

    has entered CPAN as

    file: $CPAN/authors/id/K/KA/KANE/load-0.01.tar.gz
    size: 2331 bytes
    md5: f087c55c5c296457bd0b4908dfd0952c


    It works with both barewords as variables
    here's the perldoc about it:

    NAME
    load - runtime require of both modules and files

    VERSION
    This document describes version 0.01 of load, released Nov 24, 2002.

    SYNOPSIS
    use load;

    load Data::Dumper;

    load some/script.pl;

    load thing;

    DESCRIPTION
    "load" eliminates the need to know whether you are trying to require
    either a file or a module.

    If you consult "perldoc -f require" you will see that "require" will
    behave differently when given a bareword or a string.

    In the case of a string, "require" assumes you are wanting to load a
    file. But in the case of a bareword, it assumes you mean a module.

    This gives nasty overhead when you are trying to dynamically require
    modules at runtime since you will need to change the module notation
    ("Acme::Comment") to a file notation fitting the particular platform
    you are on.

    "load" elimates the need for this overhead and will just DWYM.

    Rules
    "load" has the following rules to decide what it thinks you want:

    * If the argument has any characters in it other than those
    matching "\w" or ":", it must be a file

    * If the argument matches only "[\w:]", it must be a module

    * If the argument matches only "\w", it could either be a module
    or a file. We will try to find "file" first in "@INC" and if
    that fails, we will try to find "file.pm" in @INC. If both fail,
    we die with the respective error messages.

    TODO
    * Allow for "import()" arguments and version checks

    * Allow a compile time equivalent of load (perhaps "use load LWP")

    AUTHOR
    This module by Jos Boumans <kane@cpan.org>.

    COPYRIGHT
    This module is copyright (c) 2002 Jos Boumans <kane@cpan.org>. All
    rights reserved.

    This library is free software; you may redistribute and/or modify it
    under the same terms as Perl itself.


    patches/suggestions welcome


    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu
  • Benjamin Goldberg at Nov 24, 2002 at 6:31 pm
    Jos I. Boumans wrote:
    [snip]
    TODO
    * Allow for "import()" arguments and version checks

    * Allow a compile time equivalent of load (perhaps "use load LWP")
    I don't think that that should be necessary.

    use load LWP;

    Could easily be done as:

    use LWP ();

    The only reason for wanting a compile-time version is if you want to
    load a file (not a module) at compile-time. This can easily be done
    with:

    BEGIN { require "foo.pl" }

    --
    my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
    .."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]
  • Jos I. Boumans at Nov 24, 2002 at 6:54 pm

    Benjamin Goldberg wrote:
    Jos I. Boumans wrote:
    [snip]
    TODO
    * Allow for "import()" arguments and version checks

    * Allow a compile time equivalent of load (perhaps "use load LWP")
    I don't think that that should be necessary.
    I put that in to see if i'd get some reactions..
    i can only see value here in some string eval's and begin blocks... but
    this is such a small 'niche' that writing it out full may be good enough


    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu
  • Jan Dubois at Nov 24, 2002 at 6:46 pm

    On Sun, 24 Nov 2002 18:56:22 +0100, "Jos I. Boumans" wrote:
    The uploaded file

    load-0.01.tar.gz

    has entered CPAN as

    file: $CPAN/authors/id/K/KA/KANE/load-0.01.tar.gz
    size: 2331 bytes
    md5: f087c55c5c296457bd0b4908dfd0952c
    Are you aware that there already is a "load" pragma on CPAN?

    http://search.cpan.org/author/ELIZABETH/load-0.04/lib/load.pm

    I think it would be nice to avoid this situation of duplicate names,
    especially top-level names.

    [...]
    DESCRIPTION
    You may want to explain that "load" doesn't have the compiletime
    properties of "require": vivifying the package stash. This makes a
    difference when people use indirect object syntax:

    package MyPackage;
    sub new { }
    require Foo;
    my $obj = new Foo(@args);

    will call

    my $obj = Foo->new(@args);

    whereas

    package MyPackage;
    sub new { }
    load Foo;
    my $obj = new Foo(@args);

    will call

    my $obj = MyPackage::new(@args);

    There are several modules on CPAN that would break if "require" didn't do
    this (XML::Simple, LWP::RobotUA), so people might subconsciously expect
    this behavior from load too.

    [..]
    TODO
    * Allow for "import()" arguments and version checks
    Note that "require" itself doesn't do import() or version checks beyond
    the Perl version itself. Importing at runtime seems of dubious value to
    me.
    patches/suggestions welcome
    Cheers,
    -Jan
  • Jan Dubois at Nov 24, 2002 at 6:50 pm

    On Sun, 24 Nov 2002 10:45:53 -0800, Jan Dubois wrote:
    whereas

    package MyPackage;
    sub new { }
    load Foo;
    my $obj = new Foo(@args);

    will call

    my $obj = MyPackage::new(@args);
    Oops, make that

    my $obj = MyPackage::new(Foo(@args));

    Cheers,
    -Jan
  • Jos I. Boumans at Nov 24, 2002 at 7:01 pm

    Jan Dubois wrote:
    Are you aware that there already is a "load" pragma on CPAN?

    http://search.cpan.org/author/ELIZABETH/load-0.04/lib/load.pm

    I think it would be nice to avoid this situation of duplicate names,
    especially top-level names.
    agreed, no i wasn't aware that there was such a package.

    too bad someone brings it to my attention an hour after i upload rather
    than on thursday when i mailed about the plan =/

    according to the thesaurus, these are the synonyms:
    accouter, appoint, array, deck, equalize, fortify, furnish, gear, gird,
    guard, heel, heel up, issue, load, load up, lug iron, make ready,
    mobilize, outfit, pack, prepare, prime, protect, provide, rig, rod up,
    strengthen, supply, tote

    perhaps someone has a preference...

    You may want to explain that "load" doesn't have the compiletime
    properties of "require": vivifying the package stash. This makes a
    difference when people use indirect object syntax:

    package MyPackage;
    sub new { }
    require Foo;
    my $obj = new Foo(@args);

    will call

    my $obj = Foo->new(@args);

    whereas

    package MyPackage;
    sub new { }
    load Foo;
    my $obj = new Foo(@args);

    will call

    my $obj = MyPackage::new(@args);

    There are several modules on CPAN that would break if "require" didn't do
    this (XML::Simple, LWP::RobotUA), so people might subconsciously expect
    this behavior from load too.
    good point, i'll add this to the docs
    TODO
    * Allow for "import()" arguments and version checks

    Note that "require" itself doesn't do import() or version checks beyond
    the Perl version itself. Importing at runtime seems of dubious value to
    me.
    the fact it doesn't do version checks i've always found a pity.
    and as i've replied to benjamin, importing at runtime indeed is a bit
    dubious, and can mostly see this being used for evil tricks ;)

    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu
  • Jan Dubois at Nov 24, 2002 at 7:35 pm

    On Sun, 24 Nov 2002 20:01:50 +0100, "Jos I. Boumans" wrote:
    agreed, no i wasn't aware that there was such a package.

    too bad someone brings it to my attention an hour after i upload rather
    than on thursday when i mailed about the plan =/
    Sorry about that, I only noticed the other module when I was (foolishly)
    checking if search.cpan.org already knew about your one.

    In general I think it is the duty of the uploader to avoid duplicate names
    though. :) I wonder if Andreas could add something to PAUSE to display a
    warning when you upload a module with a name that already exists under a
    different user. Probably just an email that is being sent once the README
    unpacking is done?
    according to the thesaurus, these are the synonyms:
    accouter, appoint, array, deck, equalize, fortify, furnish, gear, gird,
    guard, heel, heel up, issue, load, load up, lug iron, make ready,
    mobilize, outfit, pack, prepare, prime, protect, provide, rig, rod up,
    strengthen, supply, tote

    perhaps someone has a preference...
    I don't like any of the above. How about "need"

    need Foo;
    my $obj = Foo->new();

    doesn't look too bad to me.
    You may want to explain that "load" doesn't have the compiletime
    properties of "require": vivifying the package stash. This makes a
    difference when people use indirect object syntax:

    package MyPackage;
    sub new { }
    require Foo;
    my $obj = new Foo(@args);

    will call

    my $obj = Foo->new(@args);
    I just realized that this is only true if you don't have MyPackage::Foo
    defined, in which case you would still end up with

    my $obj = MyPackage::new(MyPackage::Foo(@args));

    and the only way to make it always work is the ugly

    my $obj = Foo::->new(@args);

    But this is no longer related to "require" vs. "load", so you can probably
    just ignore it... :)

    Cheers,
    -Jan
  • Jan Dubois at Nov 24, 2002 at 7:46 pm

    On Sun, 24 Nov 2002 11:35:07 -0800, Jan Dubois wrote:


    according to the thesaurus, these are the synonyms:
    accouter, appoint, array, deck, equalize, fortify, furnish, gear, gird,
    guard, heel, heel up, issue, load, load up, lug iron, make ready,
    mobilize, outfit, pack, prepare, prime, protect, provide, rig, rod up,
    strengthen, supply, tote

    perhaps someone has a preference...
    I don't like any of the above. How about "need"

    need Foo;
    my $obj = Foo->new();

    doesn't look too bad to me.
    I do prefer "need" as it is pretty close to "require", but if you want an
    even shorter/funnier one, how about "got"?

    got Milk;
    my $drink = Milk::->new();

    Cheers,
    -Jan
  • Jan Dubois at Nov 24, 2002 at 8:16 pm
    On Sun, 24 Nov 2002 11:35:07 -0800, Jan Dubois wrote:

    My brain seems to be in slow motion today...
    I just realized that this is only true if you don't have MyPackage::Foo
    defined, in which case you would still end up with

    my $obj = MyPackage::new(MyPackage::Foo(@args));

    and the only way to make it always work is the ugly

    my $obj = Foo::->new(@args);

    But this is no longer related to "require" vs. "load", so you can probably
    just ignore it... :)
    Actually, it is relevant:

    Since

    my $obj = Foo::->new(@args);

    does a compile time check that the Foo:: stash exists, it does work with
    "require", but will produce a warning with "load". :(

    So with

    package MyPackage;
    sub new { }
    sub Foo { }

    you can write

    require Foo;
    my $obj = Foo::->new(@args);

    but will need something like

    load Foo;
    my $obj = "Foo"->new(@args);

    for "load".

    Cheers,
    -Jan
  • Elizabeth Mattijsen at Nov 24, 2002 at 9:07 pm

    At 20:01 +0100 11/24/02, Jos I. Boumans wrote:
    Jan Dubois wrote:
    Are you aware that there already is a "load" pragma on CPAN?
    http://search.cpan.org/author/ELIZABETH/load-0.04/lib/load.pm
    I think it would be nice to avoid this situation of duplicate names,
    especially top-level names.
    agreed, no i wasn't aware that there was such a package.
    too bad someone brings it to my attention an hour after i upload
    rather than on thursday when i mailed about the plan =/
    Sorry Jos, I figured that you _did_ know about my load.pm, since I
    mentioned it at one of the recent Amsterdam PM meetings which you
    also attended. And it was discussed quite a bit on p5p last
    September, the module was initially called jit.pm, which was
    considered to be not such a good choice.

    according to the thesaurus, these are the synonyms:
    accouter, appoint, array, deck, equalize, fortify, furnish, gear,
    gird, guard, heel, heel up, issue, load, load up, lug iron, make
    ready, mobilize, outfit, pack, prepare, prime, protect, provide,
    rig, rod up, strengthen, supply, tote
    perhaps someone has a preference...
    I think we should consider three options:

    1. combining the functionality of both modules into a single load.pm
    module. I think they could be combined, but maybe that would be too
    much of a swish army knife approach.

    2. my load.pm gets renamed to something else. I wouldn't mind that
    much, for the moment it would only involve making changes to my own
    CPAN modules (that I know of).

    3. your load.pm moves to another namespace.


    Actually, now I think of it: your load.pm is a lot like my
    Thread::Use module. Maybe this can mean the death of Thread::Use...
    ;-)



    Liz
  • Jos I. Boumans at Nov 24, 2002 at 9:57 pm

    Elizabeth Mattijsen wrote:
    At 20:01 +0100 11/24/02, Jos I. Boumans wrote:
    Sorry Jos, I figured that you _did_ know about my load.pm, since I
    mentioned it at one of the recent Amsterdam PM meetings which you also
    attended. And it was discussed quite a bit on p5p last September, the
    module was initially called jit.pm, which was considered to be not such
    a good choice.
    Yes, i *should* have known about it.. actually this is probably why i
    had the idea of 'load.pm' in my head to begin with ;)

    i remember the discussion about jit.pm, and somehow, i must have
    forgotten the rest, i surely do appologise
    I think we should consider three options:

    1. combining the functionality of both modules into a single load.pm
    module. I think they could be combined, but maybe that would be too
    much of a swish army knife approach.
    yes, it probably is too much
    2. my load.pm gets renamed to something else. I wouldn't mind that
    much, for the moment it would only involve making changes to my own CPAN
    modules (that I know of).
    well, yours is older and it's my fault for not checking...
    3. your load.pm moves to another namespace.
    that's the 'proper' thing to do.. i'm just bitter that the sweet sweet
    name 'load' is taken ;)
    but 'need' or 'got' like jan suggested are fine with me
    Actually, now I think of it: your load.pm is a lot like my Thread::Use
    module. Maybe this can mean the death of Thread::Use... ;-)
    I thought you were killing all Thread::* modules anyway? ;-p

    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu
  • Elizabeth Mattijsen at Nov 24, 2002 at 10:42 pm
    To: perl5-porters@perl.org
    From: Elizabeth Mattijsen <liz@dijkmat.nl>
    Subject: Re: FYI: load-0.01 [was: require $foo vs require Foo]
    Cc:
    Bcc:
    X-Attachments:
    At 22:57 +0100 11/24/02, Jos I. Boumans wrote:
    Elizabeth Mattijsen wrote:
    At 20:01 +0100 11/24/02, Jos I. Boumans wrote:
    Sorry Jos, I figured that you _did_ know about my load.pm, since I
    mentioned it at one of the recent Amsterdam PM meetings which you
    also attended. And it was discussed quite a bit on p5p last
    September, the module was initially called jit.pm, which was
    considered to be not such a good choice.
    Yes, i *should* have known about it.. actually this is probably why
    i had the idea of 'load.pm' in my head to begin with ;)
    great minds think alike ;-)

    3. your load.pm moves to another namespace.
    that's the 'proper' thing to do.. i'm just bitter that the sweet
    sweet name 'load' is taken ;)
    but 'need' or 'got' like jan suggested are fine with me
    Well, I'm willing to be convinced that your load.pm has more "right"
    to it then mine. Seniority of the module is not that important right
    now, I think. I doubt there is anyone but me currently using load.pm
    out there other than by indirectly some of my other CPAN modules...

    Actually, now I think of it: your load.pm is a lot like my
    Thread::Use module. Maybe this can mean the death of
    Thread::Use... ;-)
    I thought you were killing all Thread::* modules anyway? ;-p
    No no... they're just going to need forks ;-)


    Liz
  • Mark Jason Dominus at Nov 24, 2002 at 8:34 pm

    SYNOPSIS

    load some/script.pl;
    Am I missing something? Barring source filter magic (which I see
    you're not doing) this can't work because the / will be interpreted as
    division.

    Perhaps it's just a documentation bug?

    (Should be
    load 'some/script.pl';
    ?)
  • Jos I. Boumans at Nov 24, 2002 at 8:35 pm

    Mark Jason Dominus wrote:
    SYNOPSIS

    load some/script.pl;

    Am I missing something? Barring source filter magic (which I see
    you're not doing) this can't work because the / will be interpreted as
    division.

    Perhaps it's just a documentation bug?
    yup it is, already fixed on the CPAN

    thanks for noticing tho


    --

    Jos Boumans

    How do I prove I am not crazy to people who are?

    CPANPLUS http://cpanplus.sf.net
    Just another perl hacker http://japh.nu

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedNov 19, '02 at 11:02a
activeDec 11, '02 at 11:40a
posts39
users12
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase