# How to hide global variables in package?

in the package I'm writing I have a list of global variables which should not be visible from a notebook. Here's an extract of the package:

Begin["Private"];

(* Global variables *)
volumeTheorical = "Not calculated value";
absoluteErrorTheorical = "Not calculated value";
relativeErrorTheorical = "Not calculated value";
volumeReal = "Not calculated value";
absoluteErrorReal = "Not calculated value";
relativeErrorReal = "Not calculated value";
reserves = "";

constantH := 40;


and finally:

End[];
EndPackage[];


Anyway when I open a new notebook, after:

SetDirectory[StringJoin[NotebookDirectory[]]];
Needs["VolumeReserves"]


If I start to write, for example, constantH...the kernel shows me it already has it set to 40. Instead I'd like it not to be visible, so that any user can define it's own constantH and use it for something else...how can I hide them? Thanks

-
So, the variables should not be visible, but they, and their values, should still be usable, is that correct? Did you use an End in your package? What about BeginPackage and EndPackage? –  Sjoerd C. de Vries Apr 9 at 17:03
yes, the values and their values should be usable only in the package. I don't want the user to modify their values, only the package should. If I set them as Protected with SetAttributes[] it seems that the package doesn't work anymore... anyway in the end I have End[]; and then EndPackage[] –  Lory Lory Apr 9 at 17:16
Could you try saving the following in a text file ptest.m and then loading it with Needs? BeginPackage["ptest"]; fun::usage = "fun[] returns the value of f\n"; Begin["private"] ; f = 1; fun[] := f; End[]; EndPackage[]; (everything on its own line). The local symbol f can now absolutely not be seen and happily co-exists with any global f-s you may define. You can see the local value of fusing fun[] or by using its full context ptestprivatef . –  Sjoerd C. de Vries Apr 9 at 18:16
sorry for the late...I've had some work troubles. Ok, I've just tried what you wrote and it works but I don't understand how I can use it in my case... :S –  Lory Lory Apr 10 at 13:59
If your package looks the same as my example it should work the same. Are you sure there are no fundamental differences? For instance, I don't see you using BeginPackage... –  Sjoerd C. de Vries Apr 10 at 14:26
show 1 more comment