Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

[Stephen Colebourne]

On 13 September 2016 at 07:33, Sander Mak <sander.mak at luminis.eu> wrote:
>> 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.

I chose "exposes" for two reasons.
1) It seems entirely orthogonal to "exports". Exports is all about
public API, and that API should only be callable by modules that
require the exporting module. Whereas exposing something is all about
the nasty yucky internals. I don't see much overlap between the two
concepts at this point.

2) "expose" is a word with deliberately negative connotations, for the
same reasons that the original proposal suggested "weak".

I'd also argue that "exports+exposes" is a cleaner way to express the
concepts than "exports", "exports dynamic" and "exports runtime".

On the "weak module" concept, I find that it is a binary top-level
choice, yet it needs quite a lot of understanding to appreciate why it
should be there. Whereas, exports+exposes can be learnt and adjusted
more easily step by step.

Stephen