Re: package impasse?

*To*: mathgroup at smc.vnet.net*Subject*: [mg6242] Re: [mg6213] package impasse?*From*: daiyanh at mindspring.com (Daitaro Hagihara)*Date*: Sat, 1 Mar 1997 02:05:12 -0500*Sender*: owner-wri-mathgroup at wolfram.com

There seems to be a bit of unpredictability in Mma's handling of packages. I still haven't got a hang of this thing yet, but it turned out that there is a couple of solutions for variables here. Create two files and do as follows: ----- file: Lekkog.m ----- BeginPackage["Lekkog`"] Abin=5 Bajal=6 EndPackage[] --------- end ------------ -----file: Muun.m ----- BeginPackage["Muun`",{"Global`", "Lekkog`"}] Print["Abin=",Abin," Bajal=",Bajal] EndPackage[] --------- end --------- In[40]:= Abin=77 Out[40]= 77 Then you'll get this: Get["Muun`"] --> Abin=77 Bajal=6 In[42]:= Bajal=33 Out[42]= 33 And this: Get["Muun`"] --> Abin=77 Bajal=33 Suppressing name shadowing warning messages should not be a difficult task. Or better yet, expunge "Global`" from Muun` and load Muun` to start with (such as in the init`). Then every time a user makes relevant changes in definitions, reload Muun` to make those changes into effect. You can automate the whole process with an appropriate combination of read-eval-loop commands if you want. For functions, however, I couldn't find a general sol'n. The pending problem here is how to deal with parameter symbols. Two workarounds exist by using the same method as the second case above: ask users to 1) use the same function parameters or 2) clear the function symbol before defining. Needless to say, the second option has unwanted side effect of clearing everything associated with the symbol. Whichever the case, at least it's a fortunate thing that you don't have to reference Global` package explicitly. As a final remark, since you must split the source code into one consisting of modifiable variables and functions and the other for the rest, software design as well as software maintenance might get tougher. Daitaro Hagihara