The picture, however, is not always rosy. Let's imagine that the main program needs to use another module called Rater, which provides rating services for online books. In this scenario, the main program may try to take functions from both modules, as shown in the following:

But, Houston, we have a problem! The rate function was brought in from the Calculator module, but it happens to be in conflict with the other one from the Rater module. Julia automatically detects this conflict on first use, prints a warning, and, from then on, requires the programmer to use their fully qualified names to access either function:

If you are not happy with this, especially the ugly-looking warning, then there is an alternative. First, you can ask yourself whether both rate functions are actually needed in the main program. If only one rate function is needed, then just bring one into scope so that there is no more conflict:

using Calculator: interest
using Rater: rate

# Here, the rate function refers to the one defined in Rater module.

From my experience, bringing specific names into the current namespace is indeed the best choice for most use cases. The reason for this is that it will be immediately obvious which functions you depend on. Such dependency is also self-documented in the code.

Occasionally, you may need to use both rate functions. In such cases, you can solve the problem by using the regular import statement:

import Calculator
import Rater

interest_rate = Calculator.rate(100.00, 3.5)
rating = Rater.rate("Hands-On Design Patterns with Julia")

This way, it only loads the packages and does not bring any name into the current namespace. You can now refer to both rate functions with their fully qualified names—that is, Calculator.rate and Rater.rate. After creating these modules, let's move on to see how to create submodules.