a way of approximating "API internal" visibility?
DanielG
simpletangent at gmail.com
Sat May 18 06:23:37 UTC 2019
I'm working on a library spread across multiple modules/packages.
Sometimes I have symbols that I would like to share between
internal packages, but I don't want to make 'public' because then
it would be exposed to the client-facing API. To a degree this
could be gotten around by making things public internally, and
then selectively 'public import'-ing individual symbols in the
topmost client-facing module (vs. entire packages, as I'm doing
now).
However I have the following situation for which that won't work:
I have a class that's going to be visible to the client, but
inside that class I have methods that should only be accessible
to other internal packages. So neither 'public' nor 'package' is
what I want.
I already collapsed one level of what I was doing to get around
this issue (putting things in a common package even though I
would have preferred they be in separate, sibling packages), but
I'm not sure I could do that again without making a mess.
Is there some way of approximating an access specifier between
'package' and 'public'? Or am I likely just structuring things
very badly to begin with, to even have this problem? I'm not much
of a C++ guy but I'd probably resort to using 'friend' to get
around this, at least in the case of classes.
More information about the Digitalmars-d-learn
mailing list