modules, include and export

[Davide Lasagna]

Hi all, 

I have a question about modules and I am probably missing something.

Say that in file.jl I define functions foo and bar. I then create a file MyModule.jl where I include file.jl as:

module MyModule

include("file.jl")

end

At this point, in the REPL, doing import MyModule will give me access to both foo and bar. Say, however, that I only want foo to be visible from the outside, while I want bar to remain private, because it is some accessory function used in foo.

What is the preferred way to achieve this? I thought that after include("file.jl") I should have added an export foo to make it accessible to the outside, but the include function is making everything in file.jl visible.

Thanks, 

Davide

[Patrick O'Leary]

Use the "using" keyword instead of the "import" keyword, in conjunction with your (correct) intuition about "export".

module MyModule

include("file.jl")

export foo

end

...

using MyModule
foo()
MyModule.bar()

[gael....@gmail.com]

Which is asking for troubles...

I always thought that non exported objects could not be imported.

[Davide Lasagna]

Thanks Patrick.

Does this mean that there is no way to make things private? I thought that only explicitly exported symbols where accessible. 

Anyway then, what is the common approach in Julia to mark things as private? Python use single and double leading underscores, but haven't seen too much _s in JUlia code.

Davide

[Patrick O'Leary]

On Tuesday, June 10, 2014 2:39:56 PM UTC-5, Davide Lasagna wrote:

Thanks Patrick.

Does this mean that there is no way to make things private? I thought that only explicitly exported symbols where accessible. 

Anyway then, what is the common approach in Julia to mark things as private? Python use single and double leading underscores, but haven't seen too much _s in JUlia code.

Entirely by consenting-adults convention. If you're a library author, declare your public API via a combination of exports and documentation. You can adopt an additional convention if you choose, but the general consensus is that Python's dunders are ugly, at least in the context of our other syntax.

A technique that may also be appealing is to put internal, unstable implementation details into a second module with an appropriately scary name ("MyModule.Internal", etc.).

[Tobias Knopp]

The convention to make things private is to not export them. When "using" a module, which is the normal way, those non-exported modules are not visible in the current scope. They are still accessible when using the fully qualified path.

[James Porter]

The way to mark things private in Julia in my experience is simply not exporting them. They'll still be available on the Module object itself (e.g. MyModule.bar), but by not exporting them, you're signaling that they're private, the same way you do with an _ in Python.

[gael....@gmail.com]

And as we've already discussed "using" are ugly and in my opinion only make sense in the REPL. But well, that's my opinion and I'm not a language designer.

Just try to "using" a module redefining "sin", you won't try twice.

I'm also waiting for the first julia big projects and users begging "would it be possible to provide developer documentation on module Foo.jl? It's so big and intricated that I can't figure out what is used and when."

Wouldn't that make sense to allow only imports of exported functions? What's the rational of the consenting adult approach? Wouldn't it be possible to do things a la Python with the double underscore: mymod.__foo is not directly accessable, o e has to access it via mymod.__mymod_foo. Exported object could be accessable as they are and non exported object could be accessable through mymod.NotExported for instance.

[Keith Campbell]

While I like the consenting adults philosophy, and agree that export choices provide a useful signal when 'using' a module,  that signal disappears when using 'import'.  

As folks begin developing larger projects, 'import' will become more important for managing namespaces.  In those cases it would be useful to have the option of importing only exported stuff.

[Kevin Squire]

Hi Keith, 

On Thursday, June 12, 2014, Keith Campbell <keith...@gmail.com> wrote:

While I like the consenting adults philosophy, and agree that export choices provide a useful signal when 'using' a module,  that signal disappears when using 'import'.  

As folks begin developing larger projects, 'import' will become more important for managing namespaces.  In those cases it would be useful to have the option of importing only exported stuff.

If the package maintainer wants to hide "non-exported" names, she could put them in a submodule. Or it might be worth breaking the project itself up into sub modules if it has that many exports that users might find confusing or unwieldy. 

Cheers!  Kevin