Is it incorrect for a module to "use" subroutines from itself?

Discussion in 'Perl Misc' started by Henry Law, Jan 27, 2008.

  1. Henry Law

    Henry Law Guest

    I have some code of which this is the relevant part:

    package NFB::Utilities::Common;
    # ...
    our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
    db_connect get_file_gm_info
    # etc ... ('all' is defined but I've snipped it)
    ) );

    # ... other subs

    sub db_connect {
    # ...etc
    }

    sub get_file_gm_info {
    # 'db_connect' is actually in this module. The call
    # is left over from when the sub was developed in-line.
    use NFB::Utilities::Common qw(db_connect);
    }

    I'm trying the code newly-installed on a Fedora Core 6 system running
    Perl 5.8.8 and it fails to compile, complaining that (in the above
    example) "db_connect" is not exported by the NFB::Utilities::Common
    module". It's clear that it is exported. Commenting out the offending
    lines, where the module uses subroutines from itself, fixes the problem.

    That's OK: I can easily find and remove the offending lines. But the
    code runs clean on an FC5 machine also running perl 5.8.8, and on my
    Windows machine running ActiveState 5.8.8, so I'm worried that I'm
    chasing a secondary error, actually caused by something else.

    Does anyone have any insight on this? Seen it yourselves, perhaps?

    --

    Henry Law Manchester, England
     
    Henry Law, Jan 27, 2008
    #1
    1. Advertising

  2. Henry Law wrote:
    > I have some code of which this is the relevant part:
    >
    > package NFB::Utilities::Common;
    > # ...
    > our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
    > db_connect get_file_gm_info
    > # etc ... ('all' is defined but I've snipped it)
    > ) );
    >
    > # ... other subs
    >
    > sub db_connect {
    > # ...etc
    > }
    >
    > sub get_file_gm_info {
    > # 'db_connect' is actually in this module. The call
    > # is left over from when the sub was developed in-line.
    > use NFB::Utilities::Common qw(db_connect);
    > }


    To me, that use-statement makes no sense at all. You don't need to load
    the module, since it's obviously already loaded, and the "db_connect"
    symbol is already in the NFB::Utilities::Common package, so why on earth
    would you want to import it to that same package?

    HTH

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Jan 27, 2008
    #2
    1. Advertising

  3. Henry Law

    Guest

    Henry Law <> wrote:
    > I have some code of which this is the relevant part:
    >
    > package NFB::Utilities::Common;
    > # ...
    > our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
    > db_connect get_file_gm_info
    > # etc ... ('all' is defined but I've snipped it)
    > ) );


    Presumably there is also a relevant part where you
    put Exporter in ISA, or use base.

    >
    > # ... other subs
    >
    > sub db_connect {
    > # ...etc
    > }
    >
    > sub get_file_gm_info {
    > # 'db_connect' is actually in this module. The call
    > # is left over from when the sub was developed in-line.
    > use NFB::Utilities::Common qw(db_connect);
    > }
    >
    > I'm trying the code newly-installed on a Fedora Core 6 system running
    > Perl 5.8.8 and it fails to compile, complaining that (in the above
    > example) "db_connect" is not exported by the NFB::Utilities::Common
    > module". It's clear that it is exported. Commenting out the offending
    > lines, where the module uses subroutines from itself, fixes the problem.


    The "use" happens at compile time, at which point your
    @EXPORT_OK is not yet set up because that happens at run time. If
    I put the @EXPORT_OK assignment in a BEGIN block, then that particular
    problem goes away.


    > That's OK: I can easily find and remove the offending lines.


    Good, because I think they are conceptual nightmare. Why would a module
    want to import into its own name space something which is already in
    its name space to start with?

    > But the
    > code runs clean on an FC5 machine also running perl 5.8.8, and on my
    > Windows machine running ActiveState 5.8.8, so I'm worried that I'm
    > chasing a secondary error, actually caused by something else.


    I get the warning on my 5.8.8 ActiveState.
    Binary build 817 [257965] provided by ActiveState
    http://www.ActiveState.com

    Are you sure you are running the exact same code (and with it being
    initially "use"d from the exact same code) in both places?

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    The costs of publication of this article were defrayed in part by the
    payment of page charges. This article must therefore be hereby marked
    advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    this fact.
     
    , Jan 27, 2008
    #3
  4. Henry Law

    Henry Law Guest

    wrote:

    >> package NFB::Utilities::Common;
    >> # ...
    >> our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
    >> db_connect get_file_gm_info
    >> # etc ... ('all' is defined but I've snipped it)
    >> ) );

    >
    > Presumably there is also a relevant part where you
    > put Exporter in ISA, or use base.


    Yes; maybe I snipped too much, in the interests of brevity.

    >
    >> # ... other subs
    >>
    >> sub db_connect {
    >> # ...etc
    >> }
    >>
    >> sub get_file_gm_info {
    >> # 'db_connect' is actually in this module. The call
    >> # is left over from when the sub was developed in-line.
    >> use NFB::Utilities::Common qw(db_connect);
    >> }


    > The "use" happens at compile time, at which point your
    > @EXPORT_OK is not yet set up because that happens at run time. If
    > I put the @EXPORT_OK assignment in a BEGIN block, then that particular
    > problem goes away.


    Mmm, yes. But the perplexing thing is that this code (at a slightly
    earlier modification level) has been running sweetly for a year now.

    >> That's OK: I can easily find and remove the offending lines.

    >
    > Good, because I think they are conceptual nightmare. Why would a module
    > want to import into its own name space something which is already in
    > its name space to start with?


    There's no reason; the cause is mistakes on my part. It came about
    because I develop subs in-line (at which point they do need to import
    the other subs) and then move them into the package where they belong.
    Sometimes I fail to delete all the "use" statements that import stuff
    from the package they eventually get put into.

    >
    >> But the
    >> code runs clean on an FC5 machine also running perl 5.8.8, and on my
    >> Windows machine running ActiveState 5.8.8, so I'm worried that I'm
    >> chasing a secondary error, actually caused by something else.

    >
    > I get the warning on my 5.8.8 ActiveState.
    > Binary build 817 [257965] provided by ActiveState
    > http://www.ActiveState.com


    Do you indeed? I have the same build (817) and the sample code I posted
    compiles cleanly with perl -c. I sense the influence of dark matter, or
    spacemen, or spies from Redmond.

    > Are you sure you are running the exact same code (and with it being
    > initially "use"d from the exact same code) in both places?


    As sure as I am of anything. The code is tar'd on the FC5 machine where
    it runs smoothly and is then un-tar'd onto the FC6 machine where I get
    the "not exported" errors, ending up in same-named directories. But
    there is always a chance, I must admit.

    > Xho


    Thanks for trying to help. Since nobody has posted with detailed wisdom
    about some other problem that is manifesting itself like this I'll just
    write a little utility to whip through and remove the offending
    references.

    --

    Henry Law Manchester, England
     
    Henry Law, Jan 27, 2008
    #4
    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. Steven
    Replies:
    4
    Views:
    716
  2. sj
    Replies:
    6
    Views:
    380
  3. plb
    Replies:
    2
    Views:
    354
  4. Fred
    Replies:
    2
    Views:
    77
    Joe Smith
    Feb 19, 2007
  5. Tim S
    Replies:
    3
    Views:
    139
    Brian McCauley
    Jun 1, 2007
Loading...

Share This Page