I ran the code before posting - you should be fine. There is some more or less "standard boiler plate" for these things. You should read the tut's if you plan to make a lot of these things. This was just an example to get you started. You can go a long way with just a little hacking based upon this example, for first testing, you don't need to worry about ISA or Exporter actually means... just follow the example.

There really isn't any such thing as a "private subroutine" in Perl - if you know the fully qualified name, you can call the function even if the sub's name is not exported. DNAlibrary::DNAappend(...); Exporting the symbol allows you to call it without having the package name prefix. If you use EXPORT_OK(...), then you need to specifiy the routines to import in the "use DNAlibrary" statement in the caller's program.

There are various testing harnesses to do automated tests during installation, etc. Sometimes I don't fiddle with that and just put a sub called test() in the module which I don't export. Then I have a $DEBUG variable that I set to 1 when I am working the the .pm file => then some statement like: test() if $DEBUG; That way the .pm file will produce a result when you run it by itself. Sophistication varies, but you should have some sort of testing strategy so that you can validate the module's functions without some extra driver program. This will save a LOT of grief later on.

You may not have seen an "our" variable before. A "my" variable does not go in the symbol table and is not eligible for export. An "our" variable does (it has "package scope", not "lexical scope". Since all of my modules have a $VERSION, exporting it makes no sense (name would conflict with other modules). But you can print it with print DNAlibrary::$VERSION; That wouldn't work if $VERSION was a "my" variable.

Glad to help you get started. Let me know if there are troubles. For right now, put the .pm file in the same directory as the .pl file. After awhile, this will no longer be adequate but there are a number of ways to solve that problem - but that's a different subject!

The goal here was go get you started and I think the Monks have done that. I would recommend buying the "Perl Cookbook" - it has lots of useful "recipes" for common problems. Of course there are lots and lots of details about this stuff.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.