Is it a good idea to Initialize variables globally inside a package ? will they be local by default to that package ?
It often does make sense to use global variables inside your package. And sometimes, you simply can't avoid that. By global here I mean variables which are defined outside any function. There are two distinct cases here:
In all cases, global variables are useful when the package needs to store some state. There are several cases when this may be needed. I will divide them into two broad categories / sets of use cases:
While I agree that one is better off by not using global variables unless strictly necessary, I doubt that one can do without global variables in packages for all tasks. The situation is similar to static (class) variables in Java or C++: it is best to keep those to a minumum, but it is hardly possible or even desirable to completely eliminate them in all cases. The problem is so common that it has a special design pattern addressing it: the sigleton pattern, which serves to keep a single instance of a class in the system, and is, in essence, a collection of global variables (class fields).
To not make up any artificial example, here is a small excerpt from the
You can see here a bunch of global variables. The variables
Global variables, either exposed to the user or kept private to the package, can be useful, and sometimes even necessary.
A variable will be public, if it is exposed to the user, for which to happen, the standard way is to give it a usage message at the public section of the package (before
Whether or not global variables are useful and / or necessary, depends on the problem being solved by the package in question. If the package defines e.g. routines for some data transformations, then it might be that no global variables are needed. However, if the package, for example, connects to some other systems and / or otherwise communicates with something having a state, then it is rather likely that some global variables may be needed.
Global variables may also be a good way to expose some package's controls to the user. They are useful in this capacity when they store quantities on which many of the package functions depend, so that it is not possible to make them local and / or optional parameters to some particular function.
I think it is not a good idea to use global variables inside a package at all. Things you put into a package are thought to be local inside the package. However, what you can do is to make for example a certain function available for other packages that have your package loaded into their context.
This is done in the following way: You first define your package and its context which is called test in this case. If you want to make a function available for other packages, you can define a usage for that function in the exported symbols region.
Now the function fun is accessible from other packages that have the package loaded into their context. What you could do is to define a variable inside that area. This variable will then be global in the context test, but i would not recommend doing that.
I recommend reading about the usage of packages in the help of Mathematica, as others already suggested.