Script appends some objects to database log. There are 3 files - main that writes objects, lib were procs defined how to append data, and the config containing the location of the database.
The problem is that for some reason the config.db_path variable, that's imported in lib becoming invisible in the lib.apend_to_datalog. And it only happens in generic proc, non-generic works fine.
The solution is really weird - you need to import config also in main, even if it's not using it (it also works fine if you declare db_path in the lib). Why it works that way, is that a bug?
The playground (hit run button)
# config.nim
let db_path* = "/some-path"
# lib.nim
import strformat, config
type SomeData* = object
timestamp*: string
proc append_to_datalog_non_generic*(item: SomeData): void =
echo fmt"{db_path}/datalog/{item.timestamp}.log"
proc append_to_datalog*[T](item: T): void =
echo fmt"{db_path}/datalog/{item.timestamp}.log"
# main.nim
import lib
append_to_datalog(SomeData())
append(SomeData())
You can fix the error by importing config.nim in main file, to make db_path symbol available in append_to_datalog instantiation scope.
https://wandbox.org/permlink/LLb98CgBH0bzOEHP
Side note - for multifile examples I highly recommend using wandbox as it does not require login for editing & doesn't take that much time to load.
Importing config.nim from the main.nim - feels fragile and not scalable, as the changed implementation in some library - may broke the code that depends and use it.
The solution with bind looks more robust.
P.S.
I read about the bind keyword - seems like it's used mostly in templates/macros. So - it seems that the way things works now - semantics of how generics are working is different from how the plain procs are working, generics are more like template/macros thing. I would say it's not good, would be better to keep behavior of generics same as procs...
Tanks, missed that line. The doc says:
... But a bind is rarely useful because symbol binding from the definition scope is the default. ...
wondering why it didn't worked in that case and didn't binded db_path - seems like it's in the definition scope and should be by default?