So then your results would indicate that putting 'using MyModule' inside a
function *could* actually bring the exported names into only the local
scope *if* the module had already been constructed in the global scope. I
know I've seen some people discuss name pollution by 'using' too many
modules. It might be part of a wider solution to enable local scope
'using', either with a new keyword or just having 'using' check if the
module already exists.
On Wednesday, March 4, 2015 at 7:33:37 PM UTC-5, MA Laforge wrote:
>
> Josh:
> I do not fully appreciate the details of how modules get imported either.
> Here is what I can gather:
>
> module moda
> export modvar, setmodvar
> modvar = 1
> setmodvar(x) = (global modvar=x)
> end
>
> module modb
> export modvar, setmodvar
> modvar = 2
> setmodvar(x) = (global modvar=x)
> end
>
> module modc
> using moda
> import modb
> println("using moda")
> @show modvar, moda.modvar, modb.modvar
> @show setmodvar(5)
> @show modvar, moda.modvar, modb.modvar
> @show modb.setmodvar(3)
> @show modvar, moda.modvar, modb.modvar
> end
>
> module modd
> import moda
> using modb
> println("using modb")
> @show modvar, moda.modvar, modb.modvar
> @show setmodvar(8)
> @show modvar, moda.modvar, modb.modvar
> end
>
> This gives the following results:
> using moda
> (modvar,moda.modvar,modb.modvar) => (1,1,2)
> setmodvar(5) => 5
> (modvar,moda.modvar,modb.modvar) => (5,5,2)
> modb.setmodvar(3) => 3
> (modvar,moda.modvar,modb.modvar) => (5,5,3)
> using modb
> (modvar,moda.modvar,modb.modvar) => (3,5,3)
> setmodvar(8) => 8
> (modvar,moda.modvar,modb.modvar) => (8,5,8)
>
> So it looks like it is the same code in the background (at least the
> variables appear to be in a common address space).
>
> So... it looks like import merely "makes visible" the code at a module
> level...
> And "using" first "imports", then "provides a shortcut" to the exported
> variables/functions...
>
> But as far as I can tell, compilation is done "on demand". I believe that
> the "real" compile step is done when we call a particular version of the
> code. Compilation is actually a separate step from "using" and "import"
>
>
> On Tuesday, March 3, 2015 at 11:48:53 AM UTC-5, Josh Langsfeld wrote:
>>
>> I'm curious about that workaround suggested in the FAQ, where you wrap
>> the function inside its own module. What is happening under the hood there?
>> Does it reinitialize the desired module entirely inside of the wrapper
>> module or does it just make a reference to some other compiled and
>> initialized top-level area? This is assuming the module has already been
>> built elsewhere and you just want easy local access to the exported symbols.
>>
>> On Monday, March 2, 2015 at 5:59:30 PM UTC-5, [email protected] wrote:
>>>
>>> The C++ "using namespace" and Julia "using module" are not quite the
>>> same thing. The C++ namespace is a top level entity that is created and
>>> initialized as part of the C++ startup code and the "using" just makes the
>>> names of these global entities available within the scope. The Julia
>>> "using" imports, and thus creates, the module for the first time, and Julia
>>> modules can contain statements that run at initialization, whereas C++
>>> namespaces can only contain declarations.
>>>
>>> But if the Julia "using" is within the function, when should the actual
>>> import and initialize and execute the statements be done? Every time the
>>> function is called is very expensive. Hoist the import out of the function
>>> to the top level, but doing this naively (ie putting the hoisted import
>>> just before the function) will then affect all code following the function
>>> Have a "pseudo" top- level visible only to the function adds a complete
>>> new complication to the name management code. But then what happens if the
>>> module is imported into two functions, how is its initialization managed?
>>> Or the top level and the function?
>>>
>>> So for now the "simpler is better" approach is to have the user manage
>>> importing at the top level only.
>>>
>>> Cheers
>>> Lex
>>>
>>> On Tuesday, March 3, 2015 at 7:23:33 AM UTC+10, Josh Langsfeld wrote:
>>>>
>>>> It's discussed in the FAQ so there must be a good reason for it, though
>>>> no rationale is mentioned.
>>>>
>>>>
>>>> http://docs.julialang.org/en/latest/manual/faq/#can-i-use-using-or-import-inside-a-function
>>>>
>>>> On Monday, March 2, 2015 at 3:00:21 PM UTC-5, Patrick O'Leary wrote:
>>>>>
>>>>> On Saturday, February 28, 2015 at 11:06:38 AM UTC-6, MA Laforge wrote:
>>>>>>
>>>>>> C++ provides "using namespace X" to "make available" the contents of
>>>>>> X to the current scope. This even works on un-named scopes within a
>>>>>> function:
>>>>>>
>>>>>
>>>>> (etc.)
>>>>>
>>>>> I know this is something that's come up before, and I think
>>>>> rejected--I think because it causes conflicts with multiple dispatch? But
>>>>> I
>>>>> can't seem to find the thread(s).
>>>>>
>>>>> I can't create a hard conflict in a quick mental search for an
>>>>> example, but I can create some level of confusion:
>>>>>
>>>>> module Foo
>>>>> bar::Int = 1
>>>>> end
>>>>>
>>>>> module Baz
>>>>> bar::Float64 = 27.3
>>>>> with module Foo # not current Julia syntax
>>>>> bar #which bar is this?
>>>>> end
>>>>> end
>>>>>
>>>>
