3

Let us suppose we have two packages: A and B.

BeginPackage["A`"]

Foo::usage="bla bla";

Begin["`Private`"]

Foo[x_]:= x^2;
SetAttributes[Foo,{Protected,ReadProtected,Locked}];

End[]
EndPackage[]

.

BeginPackage["B`"]

Foo::usage="bla bla";

Begin["`Private`"]

Foo[x_]:= x^3;
SetAttributes[Foo,{Protected,ReadProtected,Locked}];

End[]
EndPackage[]

Obviously, if the user tries to load both packages on the same kernel, there will be shadowing issues. Normally one would just rename one of the functions to avoid that kind of conflicts. However, if both packages come from different developers and are encrypted/proprietary (i.e. there is no way to modify the source code) then the user seems to be out of luck.

So is there any possibility to load the two packages on the same kernel such, that the functions Foo from A and B will not go into the Global context? Then the user could use just A`Foo and B`Foo to distinguish between the two. Or are there possibly other tricks to have both functions in the same session?

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
vsht
  • 3,517
  • 13
  • 23
  • 2
    I don't understand the question. Foo will not go in the Global` context. If you evaluate the code you posted in a newly started kernel, you'll get A`Foo and B`Foo and you can refer to them as such. You will not get Global`Foo. Simply typing Foo will refer to B`Foo because package B was loaded last and thus B` appears first in $ContextPath. – Szabolcs Mar 19 '15 at 21:52
  • @Szabolcs You're of course correct, there's nothing going into Global here. My mistake. But I'm mainly worried about the warning messages that Mathematica issues when I load both packages. Can I really ignore them (in this case) without any issues? That would mean that I can essentially do Off[General::shdw]; Needs["A"];Needs["B`"];On[General::shdw]` without any problems, right? – vsht Mar 19 '15 at 22:20
  • and with the help of $ContextPath = Select[$ContextPath, (! StringMatchQ[#, "A`" ~~ ___] && ! StringMatchQ[#, "B`" ~~ ___]) &]; I can ensure that there will be no confusion between Foo from A and B. Hmm, this seems to be much easier than I thought. – vsht Mar 19 '15 at 22:35
  • 1
    You don't need StringMatchQ. $ContextPath should simply contain "A`", not A` followed by something. If you like, just use DeleteCases[$ContextPath, "A`"|"B`"] – Szabolcs Mar 19 '15 at 22:39
  • 1
    at least related seems this question of mine and all answers to it: – Albert Retey Mar 20 '15 at 12:15
  • @AlbertRetey Thanks, that's quite interesting. There are, however, cases when things may still go wrong, e.g. if both packages modify Mathematica's functions (D, Dot, Times etc. ) or put their variables explicitly into the global context. In this situation the safest thing (in my view) would be to start those packages on parallel kernels and communicate with them via ParallelEvaluate. Although I'm sure that I'm not the first one who got that idea. – vsht Mar 20 '15 at 17:54
  • yes, Mathematica lets you do a lot of things with namespaces and global/system symbols. It probably shouldn't allow all that but that's how things are, and I guess they'd be really hard to change. IMO code for others to use shouldn't make use of all these possibilities and if foreign code does stuff like modify system symbols or add symbols to "Global`" or other foreign contexts it probably makes sense to complain or avoid such code. Running parts of your code in a parallel kernel just to avoid shading problems seems an extreme kind of workaround, but might be justified if all else fails... – Albert Retey Mar 20 '15 at 20:40

1 Answers1

7

From the comments:

But I'm mainly worried about the warning messages that Mathematica issues when I load both packages.

If the packages are properly written, and if the symbol conflict is between two packages (and not builtins and a package function), then you can safely ignore it.

From the documentation of BeginPackage:

BeginPackage["context`"] makes context` and System` the only active contexts.

This means that when package B is loading, it should be completely unaware of the existence (or any symbol definitions from) package A. So there will be no conflict. This is not the case if there's a conflict with System` symbols, as that context is still active and visible to package B during load time.

I'm assuming that the packages follow the standard structure and don't make unusual use of $Context, $ContextPath or BeginPackage.

There's a trick you might find useful:

Block[{$ContextPath}, Needs["B`"]]

will load package B without adding it to the $ContextPath. To use functions from B, now you must refer them with their full name, including the context name. The shadowing message won't be issued because there's no shadowing anymore. There's no ambiguity when resolving symbol names typed without a context.

Aside: You might wonder why this Block works at all, here's a question about that.

Community
  • 1
Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
  • +1 btw, you seem to have left off the link to the question about Block. – Chris Degnen Mar 19 '15 at 22:55
  • Thanks, now I feel much more comfortable working with packages that use the same names! The only thing where this probably might go wrong, is when both packages would define Global`Foo[x_]:=.... Although it's not a good practice, I've already seen some packages doing that. – vsht Mar 19 '15 at 22:59
  • @Szabolcs I also would like to see the link to the question about Block. Could you please add it? – vsht Mar 20 '15 at 17:56
  • @vsht Fixed the link, sorry about that. It's not particularly interesting, it's just good to point out that Block doesn't in fact clear $ContextPath, so this doesn't break the code within. Also not that $ContextPath affects parsing, not evaluation. Thus the code literally written inside the Block won't be affected. But the code loaded by Needs will be because it is parsed only after the $ContextPath-change has taken effect. – Szabolcs Mar 20 '15 at 18:40