This might be of general interest – I have different questions regarding naming conventions, contexts, subcontexts, shadowing, etc., but I do feel that they are closely related, thus I don't really want to split this post into three.
What is the best method to name the package file, the package context, the directory of package files (or a more complex hierarchy of these files)? Which of these names must be the same? I got confused several times before, and though I always manage to solve a situation, I don't feel like I have a good understanding on how these things work.
When there are interrelated packages with different contexts where some symbols appear in all of these contexts then - when calling contexts in the same session - usually shadowing messages appear. This is useful, when such symbols have different definitions and are unintentionally named the same way, but not, in the following case. If someone has a newly introduced function option, like
Verbose, which doesn't have an
OwnValue, then it is totally unnecessary to invoke shadowing messages, as no call of
Verbosecould do any harm. There still might be difference in the overall description of
Verbosein two packages (even when all
DownValues, etc. are the same), for example their usage messages might differ, as different functions would utilize the
Verboseoption in the different packages.
What is the best way to deal with these things? Should a
Common.mpackage be introduced, and all the related packages be moved under a common context-name and/or directory? Do they have to be in the same directory?
Grouping and sub-contexts
Following point 2, when is it useful to introduce sub-contexts (e.g.
myContext`content`)? Should these be split into different files? How should these files be named? Is it necessary then to include a
Common.mtoo or is it just for convenience? What should be kept in