Strategies for avoiding and handling shadowing

Question

When dealing with namespaces in Mathematica (BeginPackage, $ContextPath ...) one is unavoidably confronted with the problem of shadowing (see e.g. question 1, question2). What are good strategies to handle or avoid these problems?

As a package developer, the most obvious strategy is to use unique names, but to be on the save side one would probably need to use very long names and prefixes like

MyPackageMyNameAndMyBirthday

This has drawbacks: the code will be harder to read than necessary, you still can't be sure about uniqueness and the names will be hard to remember and type, just to name some. (And yes, it spoils most of the fun and beauty of Mathematica).

Thus I have used other strategies like using strings instead of symbols for option names. I just have learned that this also has drawbacks and of course it is not applicable to function names.

Another problem is that as a user of a package, you can't control what the symbol names in these are: It might happen that you want to load two packages that define symbols with the same name. It might happen that you want to use a package written for an older version of Mathematica that defines a symbol with a name that meanwhile exists in the System` context. I have loaded packages (Needs) and explicitly removed the corresponding context from $ContextPath in such situations, but I feel that's somewhat hacky.

Are there better ways to deal with this?

(I found an article available by Wagner which discusses some ideas about the topic, but don't think it gives answers to the examples I gave)

EDIT 2022-08-28

since version 13 there is the new feature "$ContextAliases" which allows to use aliases like: Needs["context`"->"alias`"] which solves exactly the problem I was addressing. This questions and all answers can thus be considered "deprecated" and are only relevant for version < 13.

Answer 1

When this is unavoidable, I just refer to full contexts. This happens all the time when using Combinatorica, which defines Graph objects that conflict with V8's new built in Graph object. Here's a sample session (presented as an image to show highlighting and such):

Answer 2

I am somewhat late to the party, but anyways. While the solution to use fully qualified names is totally legitimate, I dislike it because it couples the packages together stronger than I'd like. In this answer, I desribes a simple alternative. I was discussing the worst case scenario, where you actually do need both functions with conflicting names within a single function you are writing. In most cases, it should be easy to isolate pieces of code which The technique there can be further automated.

I will reproduce here a modified version of that approach, which I like better because I don't have to deal with strings:

BeginPackage["Test0`"];
g[x_?NumericQ] := x^2;
EndPackage[]

BeginPackage["Test1`"];
g[x_?NumericQ] := x^3;
EndPackage[]

and the main package:

BeginPackage["Main`"];
f::usage = "A test function of a single  argument";

Begin["`Private`"];

start = Needs;
end = Function[cont,$ContextPath = DeleteCases[$ContextPath,cont]];

start@"Test0`";  
(*Define first delegate private function*)  
g1 = g; 
end@"Test0`"; 


start@"Test1`";
(*Define second delegate private function*)
g2 = g
end@"Test1`";

f[x_] := g1[x]*g2[x]

End[]
EndPackage[]

So, it is some work, and you still have to indicate the contexts, but if you have many functions where you need to resolve conflicts, you still need only two code sections. Also, in this way, this is not hidden in some function's long name, but is exposed on the level of package's sections. This is also more amenable to meta-programming, should you later decide to automate this further.

In any case, let's look:

??f
A test function of a single  argument
f[Main`Private`x_]:=Main`Private`g1[Main`Private`x] Main`Private`g2[Main`Private`x]

?Main`Private`g1
Main`Private`g1
Main`Private`g1=Test0`g

?Main`Private`g2
Main`Private`g2
Main`Private`g2=Test1`g

So, we see that our delegates were assigned properly resolved function names.

Answer 3

What I did for the IMTEK Mathematica Suppmenent (IMS) was to prefix every function with imsMyFunction. That worked reasonably well. As for context, as Mark pointed out you could use the full context path.

Answer 4

Since all names in System` start with an uppercase letter (or a non-letter), the easiest way to avoid name clashes with future versions of Mathematica is to start your names with lowercase letters. That doesn't prevent name clashes with other packages, of course.