think about export/using

MRC-CSO-SPHSU / LoneParentsModel.jl

An initial implementation of an ABM for social and child care

0 stars 4 forks source link

think about export/using #88

Closed mhinsch closed 2 years ago

mhinsch commented 2 years ago

This has been discussed in issue #73 before, but I wanted to give it its own issue. As I see it, using explicit imports (i.e. Using SomeModule: someFunction) has several advantages and disadvantages: Advantages

Makes it clear which parts of an API are actually used.
Avoids cluttering the namespace with all exports of a module.

Disadvantages

Maintaining the list of imports can be quite tedious.
Maintaining the list of imports can be error-prone (it's easy to forget to remove an import when a function is no longer being called).
It circumvents export control. Every symbol in a module can be imported if mentioned explicitly in a Using statement, no matter whether it was exported or not. At the very least this makes exports in project-internal modules completely pointless.

My conclusion would be that we should drop explicit imports at least for internal modules.

mhinsch commented 2 years ago

Just for the sake of completeness - alternative suggestions would be:

Remove all exports in internal modules (as they are pointless).
Remove all imports and prefix all (external) symbols by their module name.

The first one breaks convention and if we do the second one we might just as well use Java...

AtiyahElsheikh commented 2 years ago

I was actually wondering if there is an easy solution to check weather an imported / a used module / function is being used or not

mhinsch commented 2 years ago

I was actually wondering if there is an easy solution to check weather an imported / a used module / function is being used or not

I'm sure it's possible to do this somehow, but that would only solve one out of three issues and not the most important one IMO.

AtiyahElsheikh commented 2 years ago

From, A thread from discourse, the package Aqua.jl could be of help.

But in general, if this would make life easier, I am fine with that for internal modules. But it would be of course nice to see such statements in other cases.

mhinsch commented 2 years ago

Let's do that then (remove explicit imports for internal modules). Case in point, BTW - changing imports to Using ModuleName in Main.jl immediately gave errors because Create.jl doesn't export its functions.

mhinsch commented 2 years ago

If we have an agreement on this I will remove the issue.

AtiyahElsheikh commented 2 years ago

Whatever makes life easier is fine for me. But it is a nice to have if dependencies are explicit.

p.s. : Importing for me means an import statement that hints something is getting extended.

mhinsch commented 2 years ago

Whatever makes life easier is fine for me. But it is a nice to have if dependencies are explicit.

Yes, in general I agree, but I think for internal imports it's just more hassle than it's worth.

p.s. : Importing for me means an import statement that hints something is getting extended.

Yes, I was using 'import' in a generic English/CS sense not in the specific Julia sense.