Hi,
Having worked with the module system for some time now. There is one
situation I've started coming across a number of times now, that requires a
lot of boiler plate.
Opening every package of a module to another module. For example, for
dependency injection, code analysis, ect.
Basically you ha
On 14/01/2019 12:26, Kasper Nielsen wrote:
Hi,
Having worked with the module system for some time now. There is one
situation I've started coming across a number of times now, that requires a
lot of boiler plate.
Opening every package of a module to another module. For example, for
dependency in
>
> This is the type of use-case where using Lookup objects might be a
> better choice. If you can coerce the user module to pass a suitably
> privileged Lookup to the framework then the framework will be able to
> inject classes without needing to open packages to the framework. I
> think this is
On 14.01.19 17:18, Kasper Nielsen wrote:
[...]
So you need some kind of bootstrap class in every module that registers
their Lookup object somehow. And, you also have to make sure that the
bootstrap class does not make the Lookup object available to someone who
should not have access to it. This
On 14/01/2019 16:18, Kasper Nielsen wrote:
Yes, but we have found this to be equally tedious when you are trying
to aggregate multiple modules.
Because every module has to supply their own Lookup object.
So you need some kind of bootstrap class in every module that
registers their Lookup objec
On Tue, 15 Jan 2019 at 07:48, Alan Bateman wrote:
> Which library or framework is this and is there a write-up of the issues
> encountered when migrating it to use Lookup objects?
>
> -Alan
>
It is a small dependency injection/application I am trying to built on top
of the module system.
It is n
