radman has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I'm in the process of getting more familiar with writing modules since they pretty much rule. This subject has been a mystery to me for a long time until I actually took the time to read through the O'Reilly section of "Programming Perl" on Packages, Modules and Objects. Now it seems rather easily tackled.

However, there's something I'm still confused on here. So when you 'use Module qw(LIST)' it's like saying:

     BEGIN {
        require Module;
        Module->import(LIST);
     }
That much I understand. From what I understand about the -> operator, saying Module->import(LIST) is the same as saying &{$Module{import}}(LIST) correct? I also notice that there's no '$' on the front of Module so what is this symbol? I'm totally confused on this issue.

The thing that I did in learning the magic of modules, is build a very simple module like the following:

     package PerlModuleEducation1;
     use strict;
     use vars qw($someVar);
     
     sub import(@) {
        print "PerlModuleEducation1::import(\@) called.\n";
     }
     $someVar = 10;
     sub someFunc($$) {
        my ($s1,$s2) = @_;
        print "You called PerlModuleEducation1::someFunc($s1,$s2)!\n";
     }
Thus, if I use require then I can use $someVar and someFunc($$) with qualifiers. Also, if I use 'use' I can do virtually the same thing, but since the function has a prototype and use is really a BEGIN then I can use someFunc LIST. But the point being that I can use with out an error saying I have no import(LIST) function.

I originally thought that I'd have to create some anonymous hash called PerlModuleEducation1 and then put a refrence to a sub called 'import' inside it, but turns out, I can just write import as a normal function inside the .pm file and everything works fine. Why is that?

This has been R A D...

Replies are listed 'Best First'.
Re: Perl Module Education
by chipmunk (Parson) on May 18, 2001 at 22:56 UTC
    As you know the -> operator is often used with hash references: $value = $hash_ref->{'key'}; However, not every use of -> involves a hash reference.

    The use you're asking about is: Module->import(LIST); This snippet is actually very different from &{$Module{import}}(LIST). What you've got here is a method call.

    A method call is basically a subroutine call, except for two important differences; a method call respects inheritance, and the method call automatically places the package name or object reference at the beginning of @_.

    Module->import(LIST); # method call import Module (LIST); # alternate method call &Module::import('Module', LIST); # plain old subroutine call, no inhe +ritance
    Module is the name of a package, and import is a subroutine defined in that package or inherited from another package.

    You can find out more about method calls in perlmod and perlmodlib, as well as Exporter, which provides a standard import method.

Re: Perl Module Education
by arturo (Vicar) on May 18, 2001 at 22:43 UTC

    Side note: you don't normally need a & in front of a subroutine name anyhow. In fact, adding one changes the semantics slightly. But the thing to read is the following excerpt from le manpage du jour, perldoc perlop:

    "`->'" is an infix dereference operator, just as it is in C and C++. If the right side is either a `[...]', `{...}', or a `(...)' subscript, then the left side must be either a hard or symbolic reference to an array, a hash, or a subroutine respectively. (Or technically speaking, a location capable of holding a hard reference, if it's an array or hash reference being used for assignment.) See the perlreftut manpage and the perlref manpage. Otherwise, the right side is a method name or a simple scalar variable containing either the method name or a subroutine reference, and the left side must be either an object (a blessed reference) or a class name (that is, a package name). See the perlobj manpage.

    Most modules use the standard Exporter module, which provides a standardized import mothod, although you are free to write your own. Read perldoc Exporter and poke around in a few of your favorite modules to see how Exporter gets used.

    HTH

    perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); +$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth +er_name\n"'
      ...you are free to write your own...

      Funny, but I was just reading about that this afternoon in notes from a talk given by our very own Dominus. Although I must admit when I read it, I wondered if it's a GoodIdea™ to 'roll your own' version of Exporter, or conversely, if it's a BadIdea™. Any comments?

      /me goes off and checks 'import' in SuperSearch, just in case there has been previous discussion on this topic...

      Good thing I checked. Here's why:

      • Checking gave me time to think more about another question that is a level above the question I asked: "Given my current programming experience level, should I even be asking if X is a Good/Bad Thing ™?" Perhaps I should invest more time learning to work with what exists before reinventing the wheel; perhaps by un-asking the question, I have learned something...
      • I found this node which, though it doesn't directly answer my Good/Bad Thing™ question, brings up some good points.

      Still, I can't resist being curious, so if there are any ideas on whether or not writing your own import function, rather than using Exporter, is a Good/Bad Thing™, I'd be curious to hear. :-)

      Update: Two things...

      1. Changed title of my post.
      2. I don't mean to imply by asking about "good/bad" that I am questioning Dominus' judgement. :-)

      Ah ha! A package is a class and a class is a package, thus when you say 'Module->import()' you're calling a class method. I understand now. Wisdom ist gut.

      This has been R A D...
Re: Perl Module Education
by radman (Novice) on May 18, 2001 at 22:25 UTC

    Seeking the forgiveness of Perl Monks everywhere. I am sorry, I just read the help section that seems to tell me I should have posted this to Q/A instead. Many self-beatings of sorrow.

    This has been R A D...