Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate out core code from plug-able API code. #79

Open
hamishmorgan opened this issue Jul 17, 2012 · 0 comments
Open

Separate out core code from plug-able API code. #79

hamishmorgan opened this issue Jul 17, 2012 · 0 comments

Comments

@hamishmorgan
Copy link
Member

The codebase is together in a single package uk.ac.susx.mlcl.byblo, but some of the code is not always required for default functionality. I propose creating two packages, one for core code and another extras. This will make no difference to end users but will sanitise development somewhat, and make it easier for people to contribute. The new packages could be named:

  • uk.ac.susx.mlcl.byblo.core
  • uk.ac.susx.mlcl.byblo.extra

Areas that can be separated include:

  • Similarity measure classes in uk.ac.susx.mlcl.byblo.measures should be moved to uk.ac.susx.mlcl.byblo.extra.measures. This with the exception of the default measure (e.g uk.ac.susx.mlcl.byblo.measures.Jaccard) which would be moved to uk.ac.susx.mlcl.byblo.Jaccard
  • Feature re-weighting functions (which don't currently exist) could be implemented in uk.ac.susx.mlcl.byblo.extra.weightings. A default re-weighting could be implemented in uk.ac.susx.mlcl.byblo; each binary features. Obviously this all depends on extracting the re-weighting code.
  • Additional filters could also be specified in extras. Again this would require some refactoring to generalise filtering routines.

All extra code could conform to plug-able API, and probably implement a bean like structure so Byblo can be configured at run-time. For example, some similarity measures have hyper-parameters which should be listable and settable from the command line. The software would therefore need to be able to inspect all available measures at run-time, discover what hyper-parameters are available, and create command line options on the fly (now supported by JCommander).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant