I have a big file foo.nim. I split it putting all types from foo.nim in a bar.nim file.
Now foo.nim does not compile anymore
foo.nim
import bar
# procs...
while this version with include does
foo.nim
include bar
# procs...
I don't understand what import really does. For me, it was like importing symbols by a linker and I don't understand why both versions don't compile.
I don't understand what import really does. When you use import, then you have to mark the symbols which you want to import by export markers asterisk.
See
http://ssalewski.de/nimprogramming.html#_modules
Thanks @Stefan_Salewski. I was to answer that all my types are public but I checked one last time before posting and I found that one type was not!
I still had compilation errors. For instance with
bar.nim
type
Version* = object
major: uint
minor: uint
build: uint
revision: uint
foo.nim
import bar
#include bar
func getVers(major, minor, build, revision: ptr cuint) =
## Values provided by external API
major[] = 1
minor[] = 1
build[] = 1
revision[] = 1
func getVersion*: Version {.inline.} =
getVers(
cast[ptr cuint](addr result.major),
cast[ptr cuint](addr result.minor),
cast[ptr cuint](addr result.build),
cast[ptr cuint](addr result.revision)
)
func `$`*(version: Version): string =
## Stringify the version under the usual pattern
## ``major.minor.build.revision``
result = $version.major & '.' & $version.minor & '.' & $version.build & '.' & $version.revision
echo "Version=" & $getVersion()
The error is expression has no address; maybe use 'unsafeAddr' on line cast[ptr cuint](addr result.major), in VisualStudio Code.
But running nim check foo, I can see that there are previous errors and it is due to the fact that Version fields are not made public. Changing Version to the code below solved the problem and import can be used.
bar.nim
type
Version* = object
major*: uint
minor*: uint
build*: uint
revision*: uint
Now it becomes a different problem of information hiding. Do I want to have these fields visible by users? Are there problems using import? I suppose that if I import bar.nim in multiple files, I would get types redefinitions... I have to balance the advantages of both solutions.
I suppose that if I import bar.nim in multiple files, I would get types redefinitions.
I don't think so, but please let me know.
And thanks for your example, I have to mention that for objects it can be necessary to export fields too.
With imports the really fun part is cyclic imports. We have forum posts about that, I have to add that also to the book.
When you really love to write ptr cuint) and castptr cuint, I am not sure if Nim is such a good choice :-)
When you really love to write ptr cuint) and castptr cuint, I am not sure if Nim is such a good choice :-)
I simulated the call to an external API having that signature...
I suppose that if I import bar.nim in multiple files, I would get types redefinitions.
From a quick test, it does not seem to occur.
Now it becomes a different problem of information hiding. Do I want to have these fields visible by users? Are there problems using import? I suppose that if I import bar.nim in multiple files, I would get types redefinitions... I have to balance the advantages of both solutions.
As you already mentioned you won't get type redefinitions, that is kind of the point. Information hiding is of course the other purpose of modules (which is what an imported file is called in Nim). Typically you would put your type, and any proc that handles that proc in the same module, and then you can import it and the user is sure they won't be able to access something that would break the module if handled incorrectly. In your example you could for example move the $ procedure into that module so that you could echo that type. Or if you want the user to be able to read these fields, but not write them you could do template major*(v: Version): uint = v.major in your module and then hide the major field in the Version object. This means that you will be able to do echo version.major but not version.major = 100. For example:
type V = object
m: uint
# Since this is a single file we call it mm to avoid collision.
template mm(v: V): uint = v.m
var x = V(m: 100)
echo x.m
echo x.mm
x.m = 10
#x.mm = 200 # This doesn't work
I deposited on github I take again the functions of 5250/3270 and apply that on a terminal
it's not all over but it works
I finish by incorporating SFLINE a grid type incorporation (readOnly by experience rarely update) no question of doing GTK ;) [url=https://kodi.software/]Kodi[/url] [url=https://luckypatcher.cam/]Lucky Patcher[/url] [url=https://nox.tips/]nox[/url] I would like to have feedback on the one hand to settle the last beug or a function that I will not have included