You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
#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.
The Modules documentation has left me rather confused. According to that chapter, the main difference between
using
andimport
is thatusing
brings the module itself and its exports into the current scope, whileimport
only brings in the identifiers explicitly given to it. Further,importall
extendsimport
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
andimport
appear to bring the module itself into both the Main module as well as the currently scoped module. That makesusing
andimportall
behave nearly identically as far as I can tell.Using the example "MyModule" from the doc, if I do this:
then
Main.MyModule
,Foo.MyModule
,Foo.x
, andFoo.y
all exist.But if I do:
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
vsimport Module: function
. In fact, the only difference betweenusing
andimport
appears to be the ability to extend a function without fully qualifying its name. e.g., this doesn't work as an extension: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
andimport
/importall
is that exports can be extended without specifying the fully qualified path, is there really a need for both?The text was updated successfully, but these errors were encountered: