in reply to How to call Module

@EXPORT=qw(&Encrypt,&Decrypt);

You probably want

@EXPORT=qw(Encrypt Decrypt);
instead. And turn on warnings.

Update: ok, you have use warnings, just too late to catch that mistake.

Replies are listed 'Best First'.
Re^2: How to call Module
by tilly (Archbishop) on Aug 24, 2004 at 16:20 UTC
    Actually he shouldn't want to use @EXPORT at all. Use @EXPORT_OK and be explicit in the import. Always.

    This avoids confusion in tracking down where a function named foo came from.

      Well, that's a matter of taste. Also, one should say

      use base "Exporter";
      which is a better style imo than
      use Exporter; @ISA = "Exporter";

      There are other style errors too in the code, like not storing $cipher in an our variable, or at least declaring it; create the $cipher object only once (if the module allows that); either not having the useless new function or converting Encrypt and Decrypt to methods; not using the one-argument bless in the new method; using strict; calling die instead of exit on an error; etc. These are, however, minor errors, and we should probably first help the OP correcting the more serious errors of the code (ie making the code work)

      Sorry if this insulted you.

        Well, that's a matter of taste.

        It is also a matter of taste whether or not to use lots of global variables.

        Note that there is such a thing as bad taste.

        Comparing (over)using @EXPORT and globals is actually quite appropriate. The basic issue is the same: increased opportunities for code one place to collide with other code through action at a distance. When Exporter was first written, this was not understood to be a problem. But now it is, which is why its documentation now says,

        Do not export method names!

        Do not export anything else by default without a good reason!

        Exports pollute the namespace of the module user. If you must export try to use @EXPORT_OK in preference to @EXPORT and avoid short or common symbol names to reduce the risk of name clashes.

        (Emphasis in original.)

        I'll admit to barely glancing at the original code, there may be tons of other problems with it. Some of which may be debatably problems (I don't believe that base is particularly important), and some of which may be obvious areas for improvement. But I didn't notice.

        This is because my practice is to hold answers to a far higher standard than questions. After all a question usually admits to not being a good example. An answer holds itself up as an example of how to do things. So when I see a long question and a short answer, I often skip to the short answer and may comment if I don't think it should be offered as an example of how to work.