Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using vs importall #11031

Closed
s2maki opened this issue Apr 27, 2015 · 3 comments
Closed

using vs importall #11031

s2maki opened this issue Apr 27, 2015 · 3 comments
Labels
docs This change adds or pertains to documentation

Comments

@s2maki
Copy link
Contributor

s2maki commented Apr 27, 2015

The Modules documentation has left me rather confused. According to that chapter, the main difference between using and import is that using brings the module itself and its exports into the current scope, while import only brings in the identifiers explicitly given to it. Further, importall extends import by automatically importing all of the module's exports without needing to specify. The other difference is that imported functions can be extended while "used" functions cannot.

However, this doesn't jive with empirical testing. Both using and import appear to bring the module itself into both the Main module as well as the currently scoped module. That makes using and importall behave nearly identically as far as I can tell.

Using the example "MyModule" from the doc, if I do this:

module Foo
using MyModule
end

then Main.MyModule, Foo.MyModule, Foo.x, and Foo.y all exist.

But if I do:

module Foo
importall MyModule
end

then all of the same exist, even though the doc implies that only Foo.x and Foo.y should exist.

Likewise with using Module: function vs import Module: function. In fact, the only difference between using and import appears to be the ability to extend a function without fully qualifying its name. e.g., this doesn't work as an extension:

using MyModule
x(x)=x

However, MyModule.x(x)=x always works, regardless of which keyword is used to load MyModule.

Am I misunderstanding the doc, has something changed since it was written, or is the behavior I am seeing wrong? If I'm right, and the only difference between using and import/importall is that exports can be extended without specifying the fully qualified path, is there really a need for both?

@simonster
Copy link
Member

Basically, you should never use importall to import a module that's in another package, because if at some later date that package decides to export an identifier with the same name as an identifier that's already in your package, then your code may break.

However, I think we are mostly agreed that there are too many ways to get module bindings. See #8000.

@s2maki
Copy link
Contributor Author

s2maki commented Apr 27, 2015

#8000, to collapse import into using, seems like a good proposal. That said, if the observed behavior at the moment is the intended behavior, that's fine too; I can work with it either way. I'm more concerned with the fact that the documentation is misleading. It hints at behavior that isn't true, while leaving out mention of behavior that does occur. Perhaps this is why newbies are confused about how this all works.

I would propose that the doc be enhanced to explicitly define "soft" and "hard" bindings and to associate them with using and import accordingly. Then, correct the column "What is brought into scope" and remove or correct the column "Available for method extension".

Finally, it would help to mention that regardless of which module another module is imported into, it also gets automatically imported into Main.

@ihnorton ihnorton added the docs This change adds or pertains to documentation label Apr 28, 2015
@JeffBezanson
Copy link
Member

Improved by #12085

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change adds or pertains to documentation
Projects
None yet
Development

No branches or pull requests

4 participants