kinow opened a new pull request #116: URL: https://github.com/apache/commons-imaging/pull/116
Uses the approach with a POJO discussed in JIRA. It is similar to what was designed by @, https://github.com/mgmechanics/commons-imaging/blob/IMAGING-159-POJO/src/main/java/org/apache/commons/imaging/ImagingParameters.java. Some values were removed (no more verbose, that's using JUL API now), and a few more changes to how the classes and interface are organized. Still work-in-progress, aiming to discuss with @gwlucastrig and bring it to the mailing list for wider discussion. @gwlucastrig some interesting issues: - [ ] do we need a marker interface, or should `ImagingParameters` be the class with common parameters? - [ ] initially I put the classes in the `.common` package (which says in the docs that stores classes common to multiple formats), but maybe it should go to `.imaging`, to avoid circular reference between `.imaging` and `.imaging.common` - [ ] in many cases, `params` is optional, then later on the code might do a `if (params == null) params = new HashMap<>();`. But I think since we have an object now, we can have: * some cases where params are optional; so we overload the method, defining `parseAbc(InputStream is) {...}` and also `parseAbc(Parameters params, InputStream is)` (i.e. if you want to, you can define the parameters, otherwise just call the method without params, and the method will call the other overloaded method with `this.parseAbc(new AbcParameters(), is)`. * other cases it may be necessary to always have the parameters, so for this case we simply have a method with `parseAbc(Parameters params) { Objects.requireNotNull(params, ...) }`. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
