2 ms·
The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applyin
by girvo 10y ago
The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applying the asterisks to it; types.nim is funky because I was exploring a slightly different file/module structure (and having a singular place for top-level shared types that most other modules import is quite useful at times, and gets around circular dependencies), except it does end up looking slightly odd!
- nickpsecurity 10y agoI appreciate it. So, it looks weird because it's an experiment with something non-standard? Makes sense. Things stay clean overall.
- girvo 10y agoThat's it. For the most part, one would just export the symbols from given modules as needed (and a lot of the properties on some of the ref object types are needlessly exported, too, which makes it worse) One other thing is that the {.compile.} pragma in term.nim is not needed anymore, as Nim's stdlib has added a lot of those in[0], but it does show how easy it is to bridge between the two languages (and I'm not much of a C developer!) [0] https://nim-lang.org/docs/terminal.html https://nim-lang.org/docs/terminal.html
- nickpsecurity 10y agoAh. That link is the cleaner look I was expecting. Makes sense.