Introducing Modules and Functions

You cannot view this unit as you're not logged in yet. Go to Account to login.

3 Comments

  1. Rodrigo Lessa on November 15, 2020 at 7:23 am

    Hey at the end you say you don’t recommend naming modules like this. What would be your recommended way for setting up that module structure?

    • Mark Ericksen on November 15, 2020 at 7:44 am

      Good question! While using an “alias” with :as works, I think it’s simpler and clearer if the module is just named in a way that doesn’t need an :as. Imagine code in different modules using a different alias as and you have to go to the extra effort of looking it up to see if it’s the same one.

      In this example, I think it’s better to just name the module:

      alias MyApp.Customers.Orders.OrderProcessor

  2. Chad Henson on February 19, 2021 at 9:41 am

    It seems like the “alias” feature might be ripe for a decent naming strategy. I could imagine where the namespace represents a functional area of concern and not necessarily just a safeguard against two “same-named” (and arity) functions that do different things. So your function could be called OrderProcessor or you like you mentioned maybe you have a namespace called `MyApp.Orders.Purchasing` and one called `MyApp.Orders.Sales`. One namespace would encompass order processing from the perspective of sales orders and the other would encompass order processing from the perspective of purchase orders. So orders placed to you…versus placed by you. That seems like a reasonable use of aliasing code modules as a means to organize code across functional domains.

Leave a Comment

You must be logged in to post a comment.