Another +1 for the return of dynamic exports. Frameworks using reflection are such a common case that if dynamic exports are not available, users will either create weak modules for all their code, or they have to export packages that they would rather not export. While "dynamic export" is still not true encapsulation, it is a nice tradeoff between compatibility with existing frameworks and encapsulation. The exact keyword is less important to me. "dynamic" made sense to me, so would "runtime".
Both "weak" modules and the alternative proposed by Stephen would be ok. I somewhat like "weak" because it communicates that it is probably not an end solution, but a migration step instead. Paul On Tue, Sep 13, 2016 at 8:33 AM Sander Mak <sander....@luminis.eu> wrote: > > > On 13 Sep 2016, at 00:58, Stephen Colebourne <scolebou...@joda.org> > wrote: > > > > > > For the weak modules, the proposal does not provide a way to have > > packages exposed for runtime use, but not hidden at compile time. > > Given the benefits of hiding internal classes from IDEs, this seems > > rather unfortunate. > > Major +1. With private exports, we need to rely on will-power and > out-of-band knowledge again to prevent people from shooting themselves in > the foot. Given the prevalence of applications using dependency injection > frameworks (hence using `exports private), this is a non-trivial concession. > > > Here is my counter proposal, hopefully a > > relatively small conceptual change: > > Not sure whether introducing a new top-level keyword (exposes) is better > than adding a modifier keyword to exports. As was the case with `exports > dynamic`, but a better name might be `exports runtime` since that's how we > are referring to its effects in this whole discussion. For the rest, I > agree with the gist of the counter proposal. > > > Sander
