Re: Context Names Question (2)
- To: mathgroup at smc.vnet.net
- Subject: [mg4002] Re: [mg3919] Context Names Question (2)
- From: wagner at motel6.cs.colorado.edu (Dave Wagner)
- Date: Tue, 14 May 1996 02:38:36 -0400
- Organization: University of Colorado, Boulder
- Sender: owner-wri-mathgroup at wolfram.com
This thread is like a TV sitcom -- it's a classic case of mistiming
and mistaken identity. This is probably my fault, because I communicated
directly via e-mail to Xah and Allan, and mentioned a newgroup post
that either one or both of them hadn't seen yet.
In article <4muq35$mdr at dragonfly.wolfram.com>,
Allan Hayes <hay at haystack.demon.co.uk> wrote:
>is rightly concerned about my using the System context to solve Xah
>Lee's problem [mg3919] Context Names Question
>> Suppose I have two packages, TrochoidPlot and TrochoidShow for
>> example. Both packages use the option name RotationRange for
>> several of their functions.
>> Shadowing of RotationRange will occur after loading the second
Allan's first solution was to put RotationRange in the System context.
To which I replied (in an e-mail message):
>>You are defeating the whole point of contexts by doing this!
To which Allan followed up:
>But Xah's problem must be a common one - I frequently run into it.
>So, here's another try:
>at the head of each package in the class so that whenever one of
>them is loaded the context "Xah`Common`" is put on the context path.
>Then use "Xah`Common`" like I used "System`"
I don't know if Xah or Allan ever saw my first post, so I'll
expand on it here.
Although Allan's second method is on the right track, it is not as
elegant as the following feature of BeginPackage, which was (I'm
guessing) designed expressly for handling this type of problem:
BeginPackage["context1`", "context2`", ...] creates a new context for
context1`, but it also attempts to load context2`, ... if necessary,
and places those extra contexts on the context search path.
If Xah places the common symbol RotationRange in a separate package
RotationRange::usage = "...";
(save that in a file called Common.m in a directory called Trochoid within
your standard Packages directory.), then he can define each of his
other packages like this:
blah blah ... RotationRange ... blah blah
Save this in a file called Plot.m in the Trochoid directory.
Likewise for the Trochoid`Show` package. (Of course, you don't have
to use subcontexts like I'm doing, but doing so keeps all of the
Trochoid-related packages in a single directory, which ought to make
distribution to other people easier.)
Now here's the point: Allan's solution of using
BeginPackage["Trochoid`Common`"]; EndPackage at the beginning of each
of the other packages does place Trochoid`Common`on the context path,
but then the next BeginPackage["Trochoid`Plot`"] removes the Common`
package from the context path for the duration of the Plot` package.
Thus, it's necessary to refer to the common symbol explicitly as
In contrast, using the technique I've shown keeps the Common` context
on the context path during the intialization of the packages that
include it. I.e., within the Plot` package I can refer to
RotationRange without prefixing a context name to it. Problems like
Xah's are exactly the reason that BeginPackage takes more than one
The standard Statistics packages make extensive use of this technique.
(For example, every package needs the definition of Mean, Variance, etc.;
the HypothesisTests package needs the ConfidenceIntervals package,
which in turn needs the NormalDistribution packages, and so forth.)
Again, I apologize for any confusion I caused on the part of the
participants. I also probably inadequately explained the benefits
of this technique in my first post.
dbwagner at princon.com
==== [MESSAGE SEPARATOR] ====
Prev by Date:
Next by Date:
Previous by thread:
Re: Context Names Question (2)
Next by thread:
graphics cell color