I can of get what you're suggesting, and I do indeed find Nim public/private
limiting and do want a public/package-internal/module-private distinction.
I strongly suggest you to add new lines to your text though.
Packages are created to be used later. But the user's needs are different from
the creator's needs (and purposes). This should be reflected by a keyword
`impl` (e.g.). Some modules are more generic than others, because other modules
in the package import them and rely on them. Therefore, the cre
I most like `import[all]`. It is true, as @timotheecour points out in the GH
thread, that a new keyword like `importAll` is less extensible, but I'm not
sure how important that property is.
Another undiscussed question is what happens if you do:
importAll foo
export foo
".privateimport." is long, but ".all." is too short. It would be a difficult
thing to search. If I'm new to nim and see `{.all.}`, I might not know where to
learn what's going on. It almost looks like a typo. "Did they mean 'call'?"
It's so short that it's line-noise.
I'm not convinced that "pr
There is also the option of having a specific public API module that only
exposes what you want to expose. This gives the "second level" Sixte is asking
for. There's nothing stopping a consumer from importing the private modules,
but I feel that if your module makes it clear that the public modu
A [link](https://github.com/nim-lang/Nim/pull/11865) for those wanting it.
Personally, I think the qualifier "private" is a bit weird because it sounds
like it might mean "import only the private parts" which naturally makes no
sense, but then your brain has to adjust back to the sensible interp
Maybe Timothee's "private imports" are an excellent compromise. People can then
model the visibility how they prefer but the public/private distinction remains
simple.
Interesting. We do have `include` as well as `import`. I guess there may be
some situations where `include` causes trouble.
A user willing to take responsibility with the power like Spider-Man's Uncle
Ben says could `import[all] foo`. That might not be so awful.
What is missing is a 2nd level, a level in-between. E.g. a
developer/implementer wants to extend a module => ideally, he should have the
choice to import a module as "extendable". In this case, no visibility
restrictions aka "protections" will apply. But: A user of that particular
module should
And even if it does cause a bug every second full moon, you have to weight that
against the constant development friction -- "should I use package level
visibility? protected? private?" added on top of the other choices you have to
make -- "which type to use for this? how to name this field?" an
The Mac OS and Windows APIs are not written in Nim and offer an ABI, not just
an API. And the undocumented APIs were used because there were no other better
alternatives provided...
There is no proof whatsoever that a comment like "for internal use only, use
public API X instead" doesn't suffic
> Bugs don't arise from visibility violations.
Bugs arise from package clients using internal APIs that were not intended to
be public but had to be exported to get around this language limitation, because
* The API only works in the limited way it's used inside the package and
blows up for o
Okay, thank you for confirming my suspicions.
There is no fine grained visibility control in Nim. (Because I found it a
constant distraction in Java and C#. Bugs don't arise from visibility
violations.)
Typically you export the fields other modules need.
I know that appending '*' to a proc or field name gives the proc/field a public
level scope and not having it will make the scope module level (i.e. private).
Is there a means to make something a package level scope, something like Java's
protected? If not, how do people commo
15 matches
Mail list logo
