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 nil
@Udiknedormin:
#
# 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?