Disclaimer: I have no problems with standard import philosophy.
TIL that I can both import nothing from a module and alias it; my previous attempts failed, and looked like this:
# Regardless of order, this imports all symbols from `foo` into the current namespace # and allows for fully qualifying symbols from `foo` with either a `foo` or `f` prefix. import foo as f from foo import nil
My latest attempt works and approximates what imports are like in Python.
# This imports foo as f and requires fully qualifying symbols from `foo` using the `f` prefix. from foo as f import nil
I think that's pretty nifty, even if I don't end up importing things that way.
import X is broken design in general. :< It works the same as in Fortran, one of the best practices of which is "never use use without only:". ^^" It seems to me it would be much better if import X would not pull anything into global scope and from X import * (or something similar) imported all the stuff.
Anyway: nice trick, I haven't had a need for something like that yet...
Hi Jester, Thanks a lot for the tip. Today I started to get name conflicts on autogenerated imports. I have macro that scans all nim files and imports those that have tests in them.
So now I am generating :
from foo as ("t" & $i) import nilwhere i is the index in seq of module names and it works perfectly
# # Both provide baz(x:int) # import foo import bar proc main = # No conflict if the code doesn't use baz. # Unqualified use of baz causes an error because it is ambiguous. # baz(1) # Qualified uses of baz are fine. foo.baz(1) bar.baz(1)
My experience may not be representative, but the libraries I use don't have broad symbol overlap, just a few. In those cases I add the extra qualification and go on my way.
@jester I said two modules with the same name, not just two modules that provide two things with the same name. More like:
import graphics.settings import sounds.settings sth_they_share() # error: which one? settings.sth_they_share() # error: which one?