[jira] [Work logged] (IMAGING-159) There should be a Parameters class

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=540511&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-540511 ]

ASF GitHub Bot logged work on IMAGING-159:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 23/Jan/21 12:07
            Start Date: 23/Jan/21 12:07
    Worklog Time Spent: 10m 
      Work Description: 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:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 540511)
    Remaining Estimate: 0h
            Time Spent: 10m

> There should be a Parameters class
> ----------------------------------
>
>                 Key: IMAGING-159
>                 URL: https://issues.apache.org/jira/browse/IMAGING-159
>             Project: Commons Imaging
>          Issue Type: Improvement
>          Components: imaging.*
>    Affects Versions: 1.0-alpha2
>            Reporter: Benedikt Ritter
>            Assignee: Bruno P. Kinoshita
>            Priority: Major
>              Labels: github
>             Fix For: 1.0-alpha3
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently options for image I/O are defined as Maps. The leads to the problem that our code has to validate parameter types when they are used:
> {code:java}
> final Object value = params.get(PARAM_KEY_COMPRESSION);
> if (value != null) {
>   if (!(value instanceof Number)) {
>     throw new ImageWriteException(
>       "Invalid compression parameter, must be numeric: "
>          + value);
>   }
>   compression = ((Number) value).intValue();
> }
> {code}
> This can be simplified if we define a Parameters class that provides additional methods like {{public int getInt(String key)}}. The implementation could then look up the value from the map through an exception if it is null or not a number.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)