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

2016-10-11 Thread Stephen Colebourne
On 11 October 2016 at 16:14, wrote: > A couple of other problems I see with Colebourne's approach: > > - The only way to allow an exported API package to be used reflectively > is to expose it for deep reflection. That requires typing another > directive and,

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

2016-09-28 Thread Gunnar Morling
Stephen's suggestion appears as a reasonable proposal to me. "Exports" and "Exposes" feel quite intuitive. As a user, I'd wish for some more powerful syntax with wildcards, rather than only having * (everything) or a list of packages at my hands. E.g. something like: Exposes

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

2016-09-21 Thread David M. Lloyd
On 09/21/2016 12:50 AM, Jochen Theodorou wrote: On 12.09.2016 17:08, Mark Reinhold wrote: Issue summary - #ReflectiveAccessToNonExportedTypes --- Some kinds of framework libraries require reflective access to members of the non-exported types of other modules; examples

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

2016-09-20 Thread Jochen Theodorou
On 12.09.2016 17:08, Mark Reinhold wrote: Issue summary - #ReflectiveAccessToNonExportedTypes --- Some kinds of framework libraries require reflective access to members of the non-exported types of other modules; examples include dependency injection (Guice), persistence

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

2016-09-13 Thread Andrew Dinn
On 13/09/16 15:40, Alan Bateman wrote: > On 13/09/2016 15:28, Andrew Dinn wrote: > We have a number of patches coming that will align the implementation > with the current proposals and expect to have EA builds shortly too. Excellent! Thanks for the very quick response. regards, Andrew Dinn

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

2016-09-13 Thread Andrew Dinn
I understand the motivation for this change from the point of view of normal application operation. It looks to me to be in many ways an improvement on the previous proposal (dynamic exports). However, I don't really know whether it is adequate to the needs of middleware. So, I will leave it up to

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

2016-09-13 Thread Paul Bakker
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

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

2016-09-13 Thread Sander Mak
> On 13 Sep 2016, at 00:58, Stephen Colebourne 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

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

2016-09-12 Thread Stephen Colebourne
Quite a radical proposal. Overall, I think it is better, although I do have semantic and syntax concerns. I'm happy that there is a way to achieve real strong encapsulation. This seems like a good thing and will be a benefit in the long run. For the weak modules, the proposal does not provide a