using module

Discussion in 'Perl Misc' started by ela, Oct 28, 2011.

  1. ela

    ela Guest

    Somebody has already written a module called abc.pm wherein subroutine def
    is to invoke from my main program.

    I'd appreciate an example of the necessary lines because errors like "method
    cannot be found" keep appearing...

    in abc.pm, do I need "require Export"?

    in main.pl, should I write "use abc" and then "abc::def"?
    ela, Oct 28, 2011
    #1
    1. Advertising

  2. "ela" <> writes:
    > Somebody has already written a module called abc.pm wherein subroutine def
    > is to invoke from my main program.
    >
    > I'd appreciate an example of the necessary lines because errors like "method
    > cannot be found" keep appearing...


    If it is really 'method', that would mean that you are trying to
    invoke a subroutine via 'OO syntax', CLASS->method() or $obj->method()
    and this method doesn't exist.

    > in abc.pm, do I need "require Export"?
    >
    > in main.pl, should I write "use abc" and then "abc::def"?


    The standard boilerplate (ignoring any attempts at covering the
    mechanics of the Perl object model with "syntactic molasses" because it
    looks so .... DIFFERENT !!1 [*]).

    in the module (assuming it is not supposed to be used as a class)

    package abc;

    require Exporter; # ensure that Exporter is there
    our @ISA = qw(Exporter); # declare that it's a superclass
    our @EXPORT_OK = qw(sub1 sub2 sub2) # list exportable subroutines

    in the 'other file using it':

    use abc qw(sub2 sub3); # list of actually imported subs

    [*] This is actually one of these rare strokes of genius, as nicely
    exemplified by the fact that about everyone and his dog has been able
    to hush it up in order to make his favority pet language look better in
    comparison in a different way for more than a decade.
    Rainer Weikusat, Oct 28, 2011
    #2
    1. Advertising

  3. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >>
    >> require Exporter; # ensure that Exporter is there
    >> our @ISA = qw(Exporter); # declare that it's a superclass

    >
    > Inheriting from Exporter is no longer best practice.
    > Non-ancient versions of Exporter (5.57, with perl 5.8.3) will export
    > 'import', so you can say
    >
    > use Exporter "import";
    >
    > instead and avoid inheriting a whole lot of random internal Exporter
    > methods you didn't want.


    This would be more appropriately reworded as "I [meaning, you] (and
    presumably some set of other people [who summarily confused enough
    that they think that 'modern', whose actual meaning is 'currently
    fashionable', would be 'surely positive enough' to make any actual
    argument in favor of such an opinion redundant]) happen to be of the
    opinion that this shouldn't be done".

    And my reply to that would be: It's documented and it works and I've
    been using it in this way since the times of perl 5.003. So what's the
    compelling reason to change it?

    >> [*] This is actually one of these rare strokes of genius, as nicely
    >> exemplified by the fact that about everyone and his dog has been able
    >> to hush it up in order to make his favority pet language look better in
    >> comparison in a different way for more than a decade.

    >
    > There are often sound reasons for setting up inheritance at compile
    > time,


    Should I encounter one in code I write, I will consider doing so. But
    this hasn't happened in the past sixteen odd years. OTOH, something
    I've done fairly often is defining a set of related classes in a
    single file, moving some or all of them to different files as the
    code evolved and the classes became more complex. Or loading all
    modules from some top-level file because of more complex
    interdepedencies among them and just declaring inheritance
    relationships in the modules.
    Rainer Weikusat, Oct 28, 2011
    #3
  4. Rainer Weikusat <> writes:

    [...]

    > I've been using it in this way since the times of perl 5.003. So
    > what's the compelling reason to change it?


    Loosely related remark: I'm a content use of the Perl programming
    language. I'm not the least of a fan of "download stuff from the
    internet to get shit done fast" since I don't do "shit".
    Rainer Weikusat, Oct 28, 2011
    #4
  5. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:


    [...]

    > I am inclined to agree that I find chromatic et al.'s use of 'Modern
    > Perl' to mean 'Perl written according to current best practices; more
    > generally Perl treated as a serious programming language rather than a
    > quick hack' a bit trite,


    And what I find more than 'a bit trite' is this 'opinion
    marketing'. "Serious" and "how I would have done it" are two very much
    different things.

    I'm going to ignore the rest of this since you are just repeating
    yourself.
    Rainer Weikusat, Oct 28, 2011
    #5
  6. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Rainer Weikusat <> writes:
    >>

    > [use Exporter "import" vs inheriting]
    >>
    >> > I've been using it in this way since the times of perl 5.003. So
    >> > what's the compelling reason to change it?

    >>
    >> Loosely related remark: I'm a content use of the Perl programming

    > ed ^^ ^^ r
    >> language. I'm not the least of a fan of "download stuff from the
    >> internet to get shit done fast" since I don't do "shit".

    >
    > How *entirely* fascinating.
    >
    > What does that have to do with Exporter?


    For sake of completeness: This was supposed to communicate that I
    generally don't use 'Perl modules' except if using them provides some
    kind of signifcant benefit. And 'you must do as I bid you to do,
    otherwise, be prepared to face the nameless horror!' is not something
    I consider to be a valid argument in favor of 'significant benefit'.
    Actually, I think it's rather an argument against that: If there is a
    signifcant benefit, why not just name it when being asked for it?
    Rainer Weikusat, Oct 28, 2011
    #6
  7. ela

    ela Guest

    Dear Tad McClellan,

    Posting codes definitely represents the most clearestly. However, when the
    modules have copyright issues, the problem becomes more complex as that
    means I have to extract the content carefully, which is not always easy -
    and that also explains why I cannot always post the codes in my post.

    Sometimes I just need a better explanation about a concept. In this case, I
    go to check out Perl bibles, Perl 21 days, Perl beginners, etc, and then
    surf the web, but the resources just put the concept so complexly. Rainer
    Weikusat indeed solves my problem.

    I don't want to challenge the rules of this newsgroup and therefore I'd
    appreciate your advice when my problem is like this one.

    Best regards,
    Ela
    ela, Oct 30, 2011
    #7
  8. ela

    Jon Du Kim Guest

    Oh, yes, the frequently posted but never read "Posting Guidelines".
    Keep attacking those windmills!

    On 10/28/11 8:49 AM, Tad McClellan wrote:
    > Have you seen the Posting Guidelines that are posted here frequently?
    Jon Du Kim, Oct 30, 2011
    #8
  9. ela

    Jon Du Kim Guest

    I'm sorry. I couldn't help but respond to the guidelines troll.
    I'll do better in the future.

    On 10/30/11 2:31 PM, Henry Law wrote:
    > On 30/10/11 17:43, Jon Du Kim wrote:
    >> Oh, yes, the frequently posted but never read "Posting Guidelines".

    >
    > Repeat after me: "Do Not Feed The Troll".
    >
    Jon Du Kim, Oct 31, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. eric_bellard
    Replies:
    1
    Views:
    5,083
    CarlosRivera
    Oct 7, 2004
  2. Maric Michaud
    Replies:
    0
    Views:
    7,181
    Maric Michaud
    Jun 24, 2006
  3. Floris Bruynooghe
    Replies:
    1
    Views:
    331
    Floris Bruynooghe
    Dec 24, 2008
  4. Nikita Petrov
    Replies:
    2
    Views:
    104
    Gary Wright
    Apr 6, 2008
  5. Replies:
    4
    Views:
    96
    John W. Krahn
    Feb 15, 2006
Loading...

Share This Page