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.

Reply via email to