Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I've implemented this in [https://github.com/nim-lang/Nim/pull/11865](https://github.com/nim-lang/Nim/pull/11865)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
well nim files are not header files unlike C, C++ (or D's interface di files,
which we could think about in nim but that's a separate discussion), so I'm not
sure how one could avoid rebuilding main.nim if it imports foo.nim and foo.nim
changes only its private procs ; eg foo could define a public template that
call private procs. In any case, even if above rule was feasible, that's not
really a concern since a import foo {.private.} would just be instructed to
rebuild in case foo is modified, because of the {.private.}
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Private imports would create their own set of conflicting requirements for the goals of incremental compilation. You wouldn't be able to cleanly separate the public interface of a module from its private components that should not trigger a rebuild upon changing.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I too think grouping modules is the right way, for the same reasons - private to stay private, not at the user's discretion. What _@Zahary_ suggests in [https://forum.nim-lang.org/t/4293](https://forum.nim-lang.org/t/4293).
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Hi The Haxe language has that feature, you can see how they did it here: [https://haxe.org/manual/lf-access-control.html](https://haxe.org/manual/lf-access-control.html) you know, learn from their lessons about intended usage. In general, I think it's a mis-feature, since it can break my design. I only found it useful for unit testing, when the tester is in a different module, and you wish to test all the private functions as well. for what it's worth, C# has a related feature, which is the an access modifier called "internal", which means it's public for everything inside the dll (the same assembly) even if it contains numerous namespaces (modules). I think this is a better way, design-wise, though not as flexible as your suggestion.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I like the idea and would call it `{.exposePrivate.}`, because that is what is
does in my understanding.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
> IMO include is good enough. No it's not. I've expanded on why include is not good enough, see my updated post here [https://forum.nim-lang.org/t/4296#26730](https://forum.nim-lang.org/t/4296#26730)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
IMO `include` is good enough.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Maybe:
import foo {.visibility: private.}
Run
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
+1 on some kind of invisibility/private-ness override feature. Another bonus of
that is to use it as a temporary workaround if some 3rd party package has made
something "overly" private as viewed by an "expert" user. While this has come
up in the context of library writing, sometimes users of libraries understand
many of its internals and sometimes they don't. Private, not exported, is
probably the right default or at least too late to change, but it's easy to
forget a `*` export marker and easy to disagree. This proposed mechanism would
allow temporary workarounds much closer to a likely more sanitary future usage.
It might be better to call it something scarier/less similar to a token like
`private` which can be _so_ common in other prog.lang's as to lead to questions
like "why does `private` mean this negative sense in Nim but positive sense in
Foo?". `import foo {.overrideInvisibility.}` or `overridePrivate` or something.
Just some kind of word to indicate bypassing of normal-ness (to act as a
redundant cue over there being a pragma there at all). I agree that
`{.breakTheGlassAndMakeEverythingVisible.}` is severe overkill. :-)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
> include foo does this kind of, just need to include it once in the program or
> you get duplicates.
include (which is really like C's #include) is very different:
* include it once in the program or you can get duplicates, as you said
* no way to force full qualification, eg from foo import nil {.private.}
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I've edited my comment above while you posted yours ... With respect to "sticks out enough", I totally agree at the early adopter stage Nim is still in, but totally disagree for the time it reaches more widespread audience (and of course total world domination) - to many programmers, especially from a C++ / Java background, slapping a "private" or "public" onto things until the compiler is happy is a way of life.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
include foo does this kind of, just need to include it once in the program or you get duplicates.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I think import foo {. private .} sticks out enough, but feel free to recommend
something else if you have a better suggestion (that is also self-explanatory).
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
It's a good idea to have an escape hatch, but like all "break the glass" devices it should stick out as the wrong thing to do unless absolutely necessary; not sure how to achieve that, though.
`import foo {.private.}` to allows access to private fields (eg: package-level visibility)
[Does Nim need package-level visibility? - Nim
forum]([https://forum.nim-lang.org/t/4293](https://forum.nim-lang.org/t/4293))
suggested introducing package-level visibility and gave proper rationale for
why something like that; however, as noted, it would add complexity to the
language (eg: no syntax for that was suggested and it's not clear how to extend
the simple * for package-level visibility; likely a macro {.pkg.} would be
needed.
Instead, I'd like to suggest something simpler:import foo {.private.} (syntax
can be discussed) which imports symbols in foo, as if they were declared
public, eg:
foo.nim:
type Bar* = object
field1*: int
field2: float
proc bar(a:int): int = ...
Run
tfoo.nim:
import foo {.private.}
doAssert bar(10) == 10 # we can access `bar` thanks to `{.private.}` pragma
Run
The idea is to provide an escape hatch to visibility, and the user of
{.private.} knows what he's doing. In particular, changes to private symbols
are still allowed and are **not considered breaking changes**.
Since typically {.private.} would be used within boundaries of a library, this
wouldn't result in actual breakages.
Additional use cases are enabled by this feature, notably for debugging
purposes.
