A way to opt out of access restrictions on non-exported members.

[Alan Bateman]

On 18/11/2015 01:18, Paul Benedict wrote:
> I don't see how this approach could ever work in an EE container. An 
> existing module can't guess who needs to reach inside to perform 
> dependency injection, annotation or class scanning. Can't there be 
> some concept of a "trusted" module (signed?) that gives it superuser 
> access to any other module? Obviously an EE container would fit this 
> description.
>
The EE container case might not be too bad as the EE container creates 
the configuration and so could arrange additional qualified exports when 
not using services. Details TBD, it might be that the container injects 
a helper into the application configuration, maybe it wraps the entry 
point so that code to export the otherwise internal packages to the 
framework/container. Modules are a fundamental change and it's important 
that we get it right. To that end, it's important to have a number of 
frameworks/containers working with us and helping to understand and work 
through the migration issues.

-Alan