On 17/12/2024 14:21, David Lloyd wrote:
:
However, to give a counter-example, `Module` has `addUses` as well.
But if I want to call `addUses` on behalf of a module I've defined,
there is no corresponding `ModuleLayer.Controller` method so I do have
to define the extra class, and that's a bit silly. This is an example
of an easy enhancement that would not affect the integrity of the
platform, would not significantly increase maintenance burden (since
the logic would be nearly identical to its sibling methods), and would
be easy to achieve.
Module::addUses is for cases where code may need to create a SL that
loads a service that wasn't known to this module at compile time.
ML.Controller is the equivalent of the --add-exports, --add-opens,
--add-reads command line options for the boot layer. There was little
motive to work through the implications of --add-uses and --add-provides
and the ML.Controller equivalents at the time. The exception is the
agent case where instrumentation may augment the services used (or
provided).
Time has passed and I can only think of one request for --add-uses has
come up. That request didn't go very far because service binding
augments the module graph during resolution. A CLI option (or
ML.Controller equivalent) can only work reflectively, which is
post-resolution. This is of course too late for what the group
requesting this wanted. It hasn't been re-examined since then at least
not to my knowledge.
-Alan
