This isn't the first time I've seen the module prefix debate.
I don't really see what the issue is myself: you can force prefixes with the
"import ... nil" (IIRC) if you want. What really needs changing?
> When you write code, you feel necessary not to use "common names" for your
> procedures: if I have a module dedicated to reading one kind of files, I
> would avoid using read/open/parse/etc. because the probability that
> read(string) is already imported somewhere is pretty high.
Hmm I don't seem to have this problem. Perhaps it's because I'm using VSCode
(does that count as an IDE?)
I mean, one of Nim's strengths IMO is the ease of overloading. If I had a
module dedicated to reading one type of file I'd probably have a type that I'd
pass to it, aka:
proc open*(myFileObj: MyFileType, filename: string) =
or whatnot. Then I'd just call myFileType.open(filename).
But equally if you wanted to use myFileModule.open(filename) then why not?
That's fine too.
The last thing I personally would want is to _have_ to prefix modules all over
the place, but you can always specify in the import if you want to force this,
anyway.
> When you read code, you always need a full-fledged IDE. I am not arguing that
> Nim should be conveniently writable without an IDE... certainly not! However,
> I would like to be able to quickly be able to get an idea of what is coming
> from where when looking at a package on github instead of using a full-sized
> computer with a properly configured IDE each time I dare reading code.
One time, I broke my nimsuggest (think it was when it moved back to main nim
instead of being a nimble package or something?) anyway, that really sucked
because I lost my precious control-click to go to definition, and parameter
suggestions. But then, if you want your code to be specific without any of
that, can't you just use module prefixes anyway?
I don't know, maybe I misunderstand but can't really see what the problems are?
Are you thinking it'd be better if module prefixes are mandatory? Because then
you can use the import nil or whatever it is, surely?
**EDIT** Can we provide aliases for module imports currently? Perhaps that
would help being more specific without having to write long module names
everywhere. Or, maybe it'd just lead to a.theproc b.anotherproc everywhere.
