[
https://issues.apache.org/jira/browse/JOSHUA-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267687#comment-15267687
]
Kellen Sunderland commented on JOSHUA-260:
--
This isn't the kind of change that can be made overnight, so don't worry about
not looking into it by June. It's a more long term consideration, and I can
try and sell you a bit more on it next week.
If we use Guice alone the benefit it would provide is that all of our
implementations will be configured and hooked up in a single class at launch
time, based on our launch configuration. We won't have to have branchpoints in
the codebase to handle different arguments that were passed in when the library
was launched. An example of code that could be simplified (in Decoder.java)
would be:
if (joshuaConfiguration.amortized_sorting) {
Decoder.LOG(1, "Grammar sorting happening lazily on-demand.");
} else {
long pre_sort_time = System.currentTimeMillis();
for (Grammar grammar : this.grammars) {
grammar.sortGrammar(this.featureFunctions);
}
Decoder.LOG(1, String.format("Grammar sorting took %d seconds.",
(System.currentTimeMillis() - pre_sort_time) / 1000));
}
We could replace this kind of code with a subclass of Decoder that
automatically is used when a configuration option is set (in this case when the
option amortized_sorting is false). This would help keep the size of a class
like Decoder small, it spreads out the logic of the code to various subclasses
and automatically chooses the correct subclass at launch time.
So that's the benefit of just using juice and doing some OO refactoring, but
there are some nice libraries that will do some of things you have on your
wish-list. I think we can use some combination of args4j and typesafe config
to accomplish most of the functionality you want. Args4j in particular will
make it easy to generate documentation and help for any cli arguments (looks
like this is already somewhat the case for the GrammarPacker). Typesafe config
also allows you to override any configuration from the cli as an arg.
We of course don't have to make these changes all at once. We can gradually
introduce Guice and Args4j and then consider how to update the config aspects
of Joshua.
> Integrate IoC (Inversion of Control) into Joshua
>
>
> Key: JOSHUA-260
> URL: https://issues.apache.org/jira/browse/JOSHUA-260
> Project: Joshua
> Issue Type: Improvement
>Reporter: Kellen Sunderland
>
> I'd like to propose we investigate looking into using guice
> (https://github.com/google/guice) in conjunction with joshua's configuration
> system. I believe it would give us a nice way to map what is in the
> configuration to the code paths, and implementations used within Joshua. It
> also would go a long way to allowing us to integrate unit tests throughout
> all the important classes in Joshua. What does everyone think? Would IoC be
> a good pattern to adopt? Is everyone ok with using guice (versus say some
> other IoC library).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
