Overriding exported variables in Main after using, bad idea?

General Usage
1

Is there something particularly wrong about doing something like that:

module Module1
    export A,B,f,g
    ...
end

using Module1
A = Module1.A
B = Module1.B
f = Module1.f
g = Module1.g

I have a macro that does that automatically and that would allow not to have to qualify every use of Module1’s fields when working on a module.

2

In your example it is not actually necessary to redefine variables like that, unless you want to change the name of the variables. Check out this documentation (specifically the first table that talks about what is brought into scope by using different commands: http://docs.julialang.org/en/stable/manual/modules/

I’m not knowledgable enough to tell you if what you’re doing is bad practice or not but see below example:

julia> module MyModule
export A
A(s) = s +1
end
MyModule

julia> using MyModule

julia> A(1)
2

3

Yes, I’m talking about modifying MyModule, in which case you either have to use workspace() each time or MyModule.A(1) everywhere.

4

If you have other entities in Main that refer to things in the old Module1, there may be confusion.

Do you really want to keep so much in Main? The manual (workflow tips) suggests putting your testing code in its own module, e.g.

module M1Tester
using Module1

# code that involves unqualified references to Module1 exports
end

Then a fruitful workflow is

julia> include("module1.jl"); include("m1tester.jl")
[edit and save]
julia> include("module1.jl"); include("m1tester.jl")
[repeat]

(or reload for a package). The new instance of the tester sees only the latest Module1. The manual talks of restarting the REPL here, but in most cases that is unnecessary.

5

My understanding is that one reason why you have to bother with this module business in the first place is that you can’t reload cleanly your module into Main. I’ve done some testing and my method seems to work fine, I guess I’ll try to work with it for a while and see how it goes.