In large applications, developed over an extended period of time and possibly with the participation of several persons, a decision must be made whether to use a single large package or break the application into a number of conveniently grouped routines. A large single package may become unwieldy and difficult to maintain with a division of labor.

A multi-package application also has possible difficulties - especially it is to be obtained by breaking up an existing large package. The standard paradigm is that the dependencies of routines will form a tree-like structure. In an existing large package this might not be easy to discover, if it exists at all. Furthermore, a tree-like dependency structure may not correspond at all with convenient partitions considered from other perspectives.

Therefore, it would be useful to have a procedure that allows an arbitrary division of an application into packages. I have attached two small zip files that can be unzipped directly into your $UseBaseDirectory/Applications folder to create a simple ContextProblem application that illustrates the problem with the standard paradigm, and a ContextFix application that illustrates a proposed solution.

The problem is that with the standard processing of packages, and lacking a strict tree-like structure, some Public symbols can be pushed into the Private context and then of course the routines will not work as intended.

The essentials of my proposed solution are as follows: 1) Instead of restricting the system ContextPath in a package to the single package itself, put all application packages on the system ContextPath. 2) In the init.m file for the application read all packages to put the Public symbols in their proper contexts. The symbol definitions may be incorrect. 3) So Clear all the definitions of the Public symbols and also all definitions in the Private context. 4) Reread all the packages to establish the definitions with the Public symbols now known and found in their proper context. This is fairly simple to implement as the ContextFix application illustrates.

I believe this solution works but maybe a sharp computer science guy or gal will see a problem.

One feature of Version 10 is that using init.wl instead of init.m for the Application initialization file does not work.

Well, after doing all this work I find that Wolfram Community will not accept zip files, although the documentation says that it will. Therefore anyone who wants the files can write me at djmpark@comcast.net.