-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
relative importing #1342
Comments
I think the least cognitive load for the programmer is the former option — i.e. looking for relative imports before absolute ones. The down side is that it is a more complex mechanism. Whether each import is static or absolute can, however, always be determined statically, as far as I can tell, so that's probably not a huge issue. |
This seems similar in spirit to issues of "scope", where the default rules are to search local scope for a name/binding before searching global scope. I think the same behavior in this case would give the least surprising result. |
That's actually a nice way to look at it. It seems like this view would imply that these should all work: module A
export a
module B
export b
end
module C
export c
module D
export d
end
import A.*
import B.*
import C.*
import D.*
end
import A.*
import B.*
import C.*
#import D.* <= wouldn't work
import C.D.*
end
import A.*
#import B.* <= wouldn't work
import A.B.*
#import C.* <= wouldn't work
import A.C.*
#import D.* <= wouldn't work
#import C.D.* <= wouldn't work
import A.C.D.* |
Precisely, and we'd also get some namespace-like stuff for free:
|
+1 |
Branch merged. |
Quoting Stefan:
If feels really weird to have to write
import Foo.Bar.*
inside ofFoo
to import from the inner moduleBar
. One thing I can think of is to look for imports relative to the current module first and then fall back to searching relative toMain
. Another possibility would be to have a syntax for relative import, e.g.import .Bar.*
or something like that.The text was updated successfully, but these errors were encountered: