# Strategies for avoiding and handling shadowing

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)

-
I use strings for options now too and note that it is becoming more common in Mathematica functions now. I noted the discussion between you and Leonid about this. For me the only drawback is that you can't type command K to autocomplete the typing – Mike Honeychurch Jan 19 '12 at 23:45
The other drawback of string options is that you can't use ? to remind yourself of what they do, thus forcing you to dig through the manual... – J. M. Jan 20 '12 at 3:24
I have realized that there were no new answers for quite a while and this is probably more a discussion type of Questions than an Q&A type. I accepted Marks answer because I think it basically reflects what I also have experienced: if there are problems with shadowing the best is to use full contexts for the symbols you use. I prefer to even clean up my $ContextPath for those cases to avoid the red syntax highlighting and accidental use of short symbol names. Thanks everyone for answering. – Albert Retey Jan 21 '12 at 17:44 @MikeHoneychurch There's also no incorrect-syntax coloring for string options. So, a misspelled string option doesn't turn red. – Sjoerd C. de Vries May 21 '12 at 19:54 ## 4 Answers 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): - 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. -  hi, I would think this will make the code harder to read? I think prefixing the package name should have been enough, as in imtekfoo[] and imtekboo[] etc... Btw, when I program in c where it has no name scope, I used to prefix each of my functions with nma_ so I have nma_foo() and nma_boo(), but with systems that have name space constructs in them like Mathematica/Java/C++, etc..., this is no longer needed. But may be in Mathematica things are different for some reason, I am still learning it and do not know all the issues with packaging and such, other than just the basic setup. – Nasser Jan 23 '12 at 12:45 @NasserM.Abbasi, if you load the package and that package has a symbol that is also on, say, System context it may conflict. I had some occasions of this, when new stuff was introduced in M-, with names I had in some package; at some stage I decided to prefix everything with small letters and never had a problem after that. – ruebenko Jan 23 '12 at 12:51 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[MainPrivatex_]:=MainPrivateg1[MainPrivatex] MainPrivateg2[MainPrivatex]

?MainPrivateg1
MainPrivateg1
MainPrivateg1=Test0g

?MainPrivateg2
MainPrivateg2
MainPrivateg2=Test1g


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

-
 hi Leonid, I do not understand what you mean by I dislike it because it couples the packages together stronger than I'd like. Which packages are these? You mean the solution shown above using SystemGraph and CombinatoricaGraph. If so, I do not see this coupling. I actually like that in Mathematica one can write packageNamefunction, as I can see looking at the code right away where this function comes from. This reminds me of Java where one write the package name followed by the class name in the package. Called fully qualified name. Similar thing in Ada. thanks. – Nasser Jan 23 '12 at 11:54 @Nasser What I meant is that the use of fully-qualified names makes code harder to refactor. In Java, project of any significance is hard to imagine doing without IDE like Eclipse or IntelliJ Idea, which have strong refactoring support. Besides, cases like that in Java are quite rare, also because Mathematica package is on the average heavier (has more functionality) than Java class. A typical refactoring use case: package with a context MyPackage  becomes now MyLargerProjectMyPackage , if the previously stand-alone package becomes a part of a larger project. You will have then ... – Leonid Shifrin Jan 23 '12 at 12:19 @Nasser ...to hunt for all these symbols manually, which is quite error-prone. For cases you list, this is not likely to happen, but we see such cases not very often only because people yet did not start actively re-using each other's code in their projects, on an industrial level (compared say to Java). My approach makes this at least easier to do, since you have to change context names in just a few well-defined places. – Leonid Shifrin Jan 23 '12 at 12:23 Ok, thanks, was not thinking of refactoring issues. I was just thinking of the use of a basic, one level package, with some functions in it. If the package has more than one level in it, then I can see that fully qualified name might get too long and it will become harder to read. May be we should keep package names short then :) btw, in Ada there is a nice solution for this, which is a renames, here is a link adaic.org/resources/add_content/docs/95style/html/sec_5/… where it says Rename a long, fully qualified name to reduce the complexity if it becomes unwieldy – Nasser Jan 23 '12 at 12:52 Very nice, it does what I have described and what I do on certain occassions plus adds the delegate symbols -- altogether much more elegant and readable. I'm not sure whether this could fail due to evaluation order when the symbols define UpValues&Attributes, but for all regular "function" definitions that only define DownValues this should be save, I think even when considering attributes, right? – Albert Retey Jan 23 '12 at 14:22
show 1 more comment

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.

-