That certainly is cleaner, but any wrapper that operates inline and is not a permanent part of the code leaves itself vulnerable to being wrapped again and again, or having the wrapping lost or mismanaged in the update process, where the parts of the wrapper are far distant from each other. That is the type of "magic" that bothers me. The problem with environments and inline namespaces is that they are so all-inclusive. So much can be done that is unintended or just not part of what is trying to be accomplished at the moment. As code is expanded, the side effects are much more likely to become apparent. If the only external variables available are those that are explicitly shared from that external source, and that are explicitly brought into the present context, then those side effects are a lot less likely to happen, and if they do, the blame will be on the person who did not look at what they were referencing. It's the difference between swimming in the ocean and swimming in a private pool. In the ocean, I never can fully know what is swimming with me, while in a private pool, I always know. A module is a jar with a top, and everything should have to come in or go out from the jar through the top. Putting multiple modules into a single file is a mistake for that reason. Effectively, you have made the modules inline parts of a string of code, with all the felonies that can happen in that environment. Now, if there is some "make" process that puts all the modules and other pieces into a single file, that is indeed a different kettle of fish, because that single file is never to be directly edited.
That also brings up another piece of how that sharing process should work. Variables should be shared as read-only or read-write and that should create a property that can be interrogated. In other words, the sharing should be entirely in the control of the entity that shares. That would allow for the creation of commercial, black-box code at some point in all of this.
Everett L.(Rett) Williams II
Shawn Fox wrote: