As we all know, nim seperates the procedures that operate on an object from the
data of the object itself. I understand the thinking and largely agree with it.
However, a side-effect of this is that when importing an object from a module,
it is difficult to control what is being imported. Such control is useful, IMO,
not because of avoiding name conflicts (though that is nice also); but avoiding
blanket imports makes debugging faster and easier. It makes a visual scan of
the code much more obvious from any context, even from dead-tree paper
printouts.
For example, if someone showed me the following code because they had problem
with x:
import a_package
import b_package
var x = Joe()
x.something()
All I know is that Joe is a class from _somewhere_. I now get to do a
hunt-and-find exercise. Or I need to get myself to a computer, install the
packages and source, and look at it with a nim-enabled editor.
Alternatively, the imports could have been:
import a_package as a
from b_package import nil
The user would then prefix everything with the module name or alias. This
totally works, but it get very tedious the bigger the program becomes.
Another alternative is:
from a_package import Joe, something, something_else, ...........
This also works, but if Joe has 50 methods, then I either import everything as
a huge dump. Or, I import just what I need and keeping adding/removing stuff as
needed. Again, tedious, but it works.
**My suggestion: add an indicator to do well defined import of an object and
any associated methods found.**
So:
from a_package import @Joe
or perhaps
from a_package import Joe.*
The key here is to providing the compiler a way to automatically import both
Joe and any non-generic method or proc in the form of "method SSSS*(self: Joe,
...". In other words, is it a wild card that finds any proc who's first
parameter is the designated class and conforms to UFCS usage.
So, the example program would become:
from a_package import @Joe, @Larry
from b_package import process_y, @ZZ
var x = Joe()
x.something()
Now I know exactly where Joe came from by just looking at it.
While, I'm still a newbie with nim, I've been doing Python programming for six
years. I've come to appreciate the Python communities dislike of "from X import
* " (they equivalent of "import X" in nim.) It has saved me countless headache
over the years. Ironically, my background before that was in C/C++ and other
languages that embrace such open imports.
I suspect, if something like this were implemented, much of the nim community
would also eventually use such a feature as a default way of doing things.
Thoughts?
