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,
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
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
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
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
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
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
> 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
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