Restrictions about cyclic type defs and the "forwarding requirement" are
currently not in line with with nim's otherwise great flexibility, IMHO.
A "package-visibility/friendship" feature is probably needed too (but as
yglukhov said) not as a replacement of aforementioned features :)
Well, I've took some of the advice in this thread and created a macro module
trying to automate the required symbol forwarding and template generation
steps. It did survive its integration in our relatively large and complex
codebase, but some new limitations were discovered along the way. You
How about something _similar to_ child packages in Ada? [1] - where "sibling"
modules could have visibility of each others, as well as their parents private
parts.
[1]:
I don't know which solution I would appreciate most, but I should mention that
have also frequently incurred in 1), 2), 3), 4)
I'd like to suggest an alternative proposal: see
[https://forum.nim-lang.org/t/4296#26721](https://forum.nim-lang.org/t/4296#26721)
> removal of the "forwarding requirement"
oh, yes, please! forward declarations are so 90's! they can be a nice touch to
optionally have, for example when exposing a documented public API, but
mandatory??
> You can work-around this by making all fields private and by introducing
> accessor templates, but at this point everything is so tedious that it's
> clear the language needs fixing.
Sounds like the perfect job for a macro ;)
I think some `submodule` idea combined with a removal of the "forwarding
requirement" is the best way to do it but this needs an RFC. I'm not convinced
that more visibility rules would change the language for the better.
Isn't it the case though, that this can be solved by not introducing a types
module, and instead have smaller modules that implement the individual types in
a more separate way, with a clean, orthogonal and complete API?
Incidentally, this approach encourages the creation of good unit tests as
I don't want package level visibility, because once implemented it will be an
excuse to not implement proper cyclic imports support :).
@nepeckman, I've considered this work-around myself, but the problem is that it
doesn't work for object fields. You can select which procs and types to export,
but you cannot alter the fields that are marked as public.
Ah yeah, that makes sense. I've been primarily using procs to access object
fields, so I haven't run up against that problem. I definitely see the utility
of package level visibility, but I wouldn't want to introduce unnecessary
complexity to the language. I really like the cleanliness of `*`
Would it make sense to have an internal type, and a distinct public alias?
The implementation of the public functions use a private converter from the
alias to the internal type.
Never tried it though.
I don't know if this is sufficient for your purposes, but I've emulated
package-level visibility in a side project I've been developing. Each folder
has a `.nim` file that imports the other modules in the folder,
and exports the public interface of that folder. So package-level visibility is
I'm getting more and more convinced that Nim needs package-level visibility (or
some other similar mechanism). In our own codebases, we are repeatedly running
into instances of the following problematic pattern:
1) You try to break your code into multiple small modules.
2) Your modules need to
15 matches
Mail list logo
