Indeed this appears to be the intent: "export" tells the user what you want
to be his/her interface.
But I have also noticed myself omitting "exports" in order to avoid
collisions with elements that cannot be resolved by multi-dispatch (like
type constructors):
module Electronics
type Circuit ... end #Name is very common... don't "export"
end
module RailSystem
type Circuit ... end #Name is very common... don't "export"
end
using Electronics
using RailSystem #No collision with Circuit: because it is not exported
eckt = Electronics.Circuit("rectifier")
railckt = RailSystem.Circuit("Line A")
Otherwise, I would have to use more verbose names (which just seems silly
to me):
Electronics.Circuit -> Electronics.ElectronicCircuit #Not a common name:
should be ok to export
RailSystem.Circuit -> RailSystem.RailCircuit #Not a common name: should be
ok to export
...And maybe that's simply how modules should be defined: Never export
elements that cannot be resolved by multi-dispatch.
On Tuesday, March 3, 2015 at 8:52:20 AM UTC-5, Patrick O'Leary wrote:
>
> On Monday, March 2, 2015 at 7:45:02 PM UTC-6, MA Laforge wrote:
>>
>> Your comment sounds alot like what Stefan said:
>> https://groups.google.com/d/msg/julia-users/UvBff9QVKaA/P10-LRLezCUJ
>>
>> I admit I don't fully appreciate why this is a *technical* problem. Most
>> scoping rules would dictate that you should be referring to the *most
>> local* version of the value. In your case bar would come from module Foo.
>>
>
> One counterargument to that is that it makes the most local thing
> nonlocal--it's an unexported part of Foo. The export list is in part a
> declaration of "I'm okay with these things sharing namespace if you want,"
> and if you did `export bar` from Foo, then `import Foo`, you'd get what you
> wanted.
>
> (There's a side discussion about things happening inside functions; I'm
> not concerned about that here because that can only make things more
> complicated.)
>
