[
https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=676032&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676032
]
ASF GitHub Bot logged work on IMAGING-159:
------------------------------------------
Author: ASF GitHub Bot
Created on: 04/Nov/21 01:52
Start Date: 04/Nov/21 01:52
Worklog Time Spent: 10m
Work Description: 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
Issue Time Tracking
-------------------
Worklog Id: (was: 676032)
Time Spent: 12h 40m (was: 12.5h)
> 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: 12h 40m
> 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)
