Add infrastructure for typed dataset plugins
- Dominant language
- Java
- Stars
- 12
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Description
It would be nice if we provided a template class for designing plugins that only work with certain types of Datasets. For instance the user might make a plugin that only works with unsigned byte type data. (This is similar to IJ1's DOES_RGB, DOES_ALL, etc.) We need to provide ways to get the type of a Dataset for checking. If we could make the template class check parameters at init time (and not when run() is called) that would be great. This would simplify plugin developers lives.
However a template class approach may be too limiting in that we really need multiple inheritance to cover the flexibility of our other plugin base class implementations. So maybe instead we provide interfaces and helper methods.
Another possibility is to have all plugins have a precheck() method with current abstract base classes providing empty ones. And plugin developers could provide their own implementation. The precheck would happen after @Parameters assignment and maybe after initializers were run but before run() is ever called.
(See also `ImgPlusService`.)
Migrated-From: http://trac.imagej.net/ticket/1945
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading ImgPlusService and the existing abstract plugin base classes mentioned in the issue. Compare the proposed typed Dataset checks, initialization-time validation, and precheck() alternative, then define one approach that supports the required plugin flexibility. Done means plugin parameters are checked before run() and plugin developers have a clear way to restrict Dataset types.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100