darkma773r commented on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-959156762


   I just had another thought on this: it strikes me that the main issue with 
the generic `ImagerParser<P extends ImagingParameters>` format is how to deal 
with format-agnostic code, mainly the utility methods in `Imaging`. In other 
words, how do users specify parameters when they don't even know what the 
format is? The current approach is to have users pass in their own parameters 
objects to these utility methods but this gets into the problem of what happens 
when they pass the wrong parameters type. What if we flipped this? Instead of 
having the users create the parameters object, we have the parser create one 
and then have the user modify it as needed in a callback. So, instead of this
   ```
   public static byte[] getICCProfileBytes(final File file, final 
ImagingParameters params) {
        // hopefully params is of the correct type!
   }
   ```
   we do this
   ```
   public static byte[] getICCProfileBytes(final File file, final 
Consumer<ImagingParameters> configurer) {
        ImageParser<?> parser = ...; // get the parser
        return getICCProfileBytes(parser, configurer);
   }
   
   private static <P extends ImagingParameters> byte[] getICCProfileBytes(final 
ImageParser<P> parser, final Consumer<ImagingParameters> configurer) {
        P params = parser.getDefaultParameters();
        if (configurer != null) {
                // let the caller configure the parameters
                configurer.accept(params);
        }
        
        // params is known to be the correct type
        return parser.getICCProfileBytes(params);
   }
   ```
   Users would then call it like this:
   ```
   Imaging.getICCProfileBytes(file, p -> p.setStrict(true));
   ```
   
   We could also add methods to `ImageParser` that accept consumers like this 
for consistency. That would probably be best.
   
   Thoughts?


-- 
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.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to