Creating Mathematica packages
Package creation is a large topic indeed. I will still attempt to give a minimal clarification of the encapsulation mechanism behind packages, since in my experience it pays off to understand it.
What constitutes a package
Basically, a piece of Mathematica code (usually containing a number of variable and function definitions), which is placed inside
Begin[someContext]
code
End[]
can be called a package. Usually, however, at least some more structure is present. In particular, to separate interface from implementation, the typical package looks like
BeginPackage[someContext]
public-functions-usage-messages
Begin["`Private`"]
code
End[]
EndPackage[]
Contexts and symbol names
The context here is a namespace. The convention is that context name is a string ending with "`". At any given moment, the value for the current working namespace is stored in the system variable $Context, and can also be queried by calling Context[]. Begin["test`"] will simply add the current context to the context stack, and then change it to "test`", while End[] will exit the current context by making the previous one current.
Every symbol must belong to some context. The system commands belong to the "System`" context, and the default working context for interactive FrontEnd sessions is "Global`". When mma code is parsed, the symbols are given their "true" (long) names, which contain both a symbol name and a context where the symbol is. For example, Map is really System`Map, and if I define a function f[x_]:=x^2 in the FE session, it will be Global`f. For any symbol, one can call Context[symbol] to determine the context where that symbol belongs. To "export" a symbol defined in a package, it is sufficient to simply use it in any way in the "public" part of the package, that is, before "`Private`" or other sub-contexts are entered. Usage messages is just one way to do it, one in principle could just write sym; and the sym would be created in the main package context just the same (although this practice is discouraged).
Every symbol can be referenced by its long name. Using the short name for a symbol is acceptable if the context where it belongs belongs to the list of contexts currently on the search path, stored in a variable $ContextPath. If there is more than one context on the $ContextPath, containing the symbol with the same short name, a symbol search ambiguity arises, which is called shadowing. This problem should be avoided, either by not loading packages with conflicting public (exported) symbols at the same time, or by referring to a symbol by its long name. I discussed this mechanics in slightly more detail in this post.
Contexts can be nested. In particular, the "`Private`" above is a sub-context of the main context someContext. When the package is loaded with Get or Needs,only its main context is added to the $ContextPath. Symbols created in sub-contexts are therefore inaccessible by their short names, which naturally creates the encapsulation mechanism. They can be accessed by their full long names however, which is occasionally handy for debugging.
Storing and loading packages
Packages are stored in files with ".m" extension. It is recommended that the name of the package coincides with the name of the package context. For the system to find a package, it must be placed into some of the locations specified in the system variable $Path. As a quick alternative (useful at the development stage), $Path can be appended with the location of a directory that contains a package.
When the Needs or Get command are called, the package is read into a current context.
What is meant by this is that the package is read, parsed and executed, so that the definitions it contains are added to the global rule base. Then, its context name is added to the current $ContextPath. This makes the public symbols in a package accessible within the current working context by their short names. If a package A is loaded by another package B, then generally the public symbols of A will not be accessible in the context C which loads B - if needed, the A package must generally be explicitly loaded into C.
If the package has been loaded once during the work session, its functions can be accessed by their long names even if it is not currently on the $ContextPath. Typically, one would just call Needs again - if the package has been loaded already, Needs does not call Get but merely adds its context name to the $ContextPath. The internal variable $Packages contains a list of currently read in packages.
The case at hand
Here is how a package might look like:
BeginPackage["SimpleArithmetic`"]
AddTwo::usage = "AddTwo[a, b] returns a+b";
AddThree::usage = "AddThree[a, b, c] returns a+b+c";
TimesTwo::usage = "TimesTwo[a, b] returns a*b";
TimesThree::usage = "TimesThree[a, b, c] returns a*b*c";
Begin["`Private`"]
plus[args___] := Plus[args];
times[args___] := Times[args]
AddTwo[a_, b_] := plus[a, b];
AddThree[a_, b_, c_] := plus[a, b, c];
TimesTwo[a_, b_] := times[a, b];
TimesThree[a_, b_, c_] := times[a, b, c];
End[]
EndPackage[]
The functions AddTwo, AddThree, TimesTwo,TimesThree are public because these symbols were used in the public part of the package. Their long names would be then SimpleArithmetic`AddTwo, SimpleArithmetic`AddThree, SimpleArithmetic`TimesTwo, SimpleArithmetic`TimesThree. The functions plus and times are private to the package, since they are in the sub-context `Private`, which is not added to the ContextPath when the main package is loaded. Note that this is the only reason they are private. Should I call AppendTo[$ContextPath,SimpleArithmetic`Private`], and they'd become as "public" as the main functions (practice that should of course be discouraged by which should clarify the encapsulation mechanism).
With regards to splitting a package into several packages, this is a normal practice, but usually an individual mma package contains much more functionality than say a typical Java class, more like Java package. So, in the case at hand, I'd not split it until you get a much more functionality in it.
Of course, I only discussed here a very small subset of things related to packages. I will hopefully update this tutorial soon. An excellent reference for writing packages is a book of Roman Maeder "Programming in Mathematica". It is pretty old, but still one of the most (if not the most) useful accounts on the matter.
I think what confuses most users who are new to packages is the larger question of where to put them and how to use them. I am going to discuss this in a larger context.
Suppose you are working on some significant or extended topic, which we will call TopicX. This topic might include many notebooks of various kinds and several packages, and perhaps later WRI style paclet documentation.
First you need a place to collect all your work on TopicX. The best place to collect this is in a TopicX folder in your private Applications folder. You can find this Applications folder by evaluating $UserBaseDirectory in Mathematica and then looking for the pre-existing Applications folder. Many users find some reason to put their applications elsewhere, but I think this is the best and standard location for a number of reasons, which I won't expound on here.
Within the TopicX folder you could build a folder structure for your own notebooks and other files associated with the topic, according to your own preferences. So far, no package.
As you work on the topic you will find it convenient to develop various routines associated with the project. You might develop them in a notebook proper and then move them to a Routines section at the top of the notebook. You might leave a routine there for a while and even copy it from notebook to notebook until you are satisfied that it works properly. I often call this "package purgatory". For these routines write usage messages, a SyntaxInformation statement, Attributes if any, Options definitions if any, error messages if the routine checks for errors. If all this is done, the routine is ready for "package heaven".
An application may have more than one package associated with it. I am going to assume that this is the case, or a future possibility, and give the packages names other than TopicX. So let's assume that your first package will be named Package1. In the TopicX folder create a new file named Package1.m. You could do this by opening Mathematica, using Create New> Other> Package, and then saving the file as Package1.m in your TopicX folder.
Package files can have sectional organization just as regular notebooks. You may wish to create sectional organization for the BeginPackage and Usage messages, and for the Private section, and for an End section. You may also want subsections for individual routines. According to your taste. Package files can also contain Text cells for annotation or notes.
The actual Mathematica code in a Package file is contained in Code cells. These are automatically Initialization cells and they are evaluated when the package is loaded. Cells that have the Input Style are not part of the package. (Converting a Code cell to an Input cell is a way to save an old version of a routine.) You can copy your routines from the notebook where they were developed to the package file. Usage messages to the Usage section and code to the Private section. Depending on how you copy you may have to switch Input cells to Code cells using the context Style menu. Code cells, especially usage messages often do not conveniently break and require horizontal scrolling. Sometimes it helps to temporarily switch them to Input cells for editing.
Following the folder structure, the BeginPackage statement will be:
BeginPackage["TopicX`Package1`"]
and the package could be loaded from anywhere with:
<< TopicX`Package1`
However, there is another very convenient feature that WRI has implemented. If a user executes the load statement without the package name as follows:
<< TopicX`
then Mathematica looks for an init.m file within a TopicX/Kernel folder and evaluates it.
So create a Kernel folder within TopicX and an init.m file within it, and include the statements:
Get["TopicX`Package1`"]
Get["TopicX`Package2`"]
if there are other packages in the application.
That's it. I won't discuss the details of package code since that is pretty well discussed elsewhere.
Later, if you want to add WRI paclet documentation, you could obtain Wolfram Workbench. You could just transfer the package files to Workbench and start writing Guide and Function pages. One important thing to remember is that all the routines from all the packages in TopicX are included in a single documentation paclet for TopicX.
You'll want to at least look at chapters 1-2 of Roman Maeder's Programming in Mathematica for starters. That was the walkthrough I used when I was starting out with package writing.
In particular, the book provides the listing of a template package file, named Skeleton.m. Here is what it looks like:
(* :Title: Skeleton.m -- a package template *)
(* :Context: ProgrammingInMathematica`Skeleton` *)
(* :Author: Roman E. Maeder *)
(* :Summary:
The skeleton package is a syntactically correct framework for package
development.
*)
(* :Copyright: © <year> by <name or institution> *)
(* :Package Version: 2.0 *)
(* :Mathematica Version: 3.0 *)
(* :History:
2.0 for Programming in Mathematica, 3rd ed.
1.1 for Programming in Mathematica, 2nd ed.
1.0 for Programming in Mathematica, 1st ed.
*)
(* :Keywords: template, skeleton, package *)
(* :Sources:
Roman E. Maeder. Programming in Mathematica, 3rd ed. Addison-Wesley, 1996.
*)
(* :Warnings:
<description of global effects, incompatibilities>
*)
(* :Limitations:
<special cases not handled, known problems>
*)
(* :Discussion:
<description of algorithm, information for experts>
*)
(* :Requirements:
ProgrammingInMathematica/Package1.m
ProgrammingInMathematica/Package2.m
ProgrammingInMathematica/Package3.m
*)
(* :Examples:
<sample input that demonstrates the features of this package>
*)
(* set up the package context, including public imports *)
BeginPackage["ProgrammingInMathematica`Skeleton`", "ProgrammingInMathematica`Package1`", "ProgrammingInMathematica`Package2`"]
(* usage messages for the exported functions and the context itself *)
Skeleton::usage = "Skeleton.m is a package that does nothing."
Function1::usage = "Function1[n] does nothing."
Function2::usage = "Function2[n, (m : 17)] does even more nothing."
(* error messages for the exported objects *)
Skeleton::badarg = "You twit, you called `1` with argument `2`!"
Begin["`Private`"] (* begin the private context (implementation part) *)
Needs["ProgrammingInMathematica`Package3`"] (* read in any hidden imports *)
(* unprotect any system functions for which definitions will be made *)
protected = Unprotect[ Sin, Cos ]
(* definition of auxiliary functions and local (static) variables *)
Aux[f_] := Do[something]
staticvar = 0
(* definition of the exported functions *)
Function1[n_] := n
Function2[n_, m_ : 17] := n m /; n < 5 || Message[Skeleton::badarg, Function2, n]
(* definitions for system functions *)
Sin /: Sin[x_]^2 := 1 - Cos[x]^2
Protect[ Evaluate[protected] ] (* restore protection of system symbols *)
End[ ] (* end the private context *)
Protect[ Function1, Function2 ] (* protect exported symbols *)
EndPackage[ ] (* end the package context *)
For your own package, just modify, replace and/or delete stuff from the template as needed.