[
https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=676756&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676756
]
ASF GitHub Bot logged work on IMAGING-159:
------------------------------------------
Author: ASF GitHub Bot
Created on: 04/Nov/21 21:55
Start Date: 04/Nov/21 21:55
Worklog Time Spent: 10m
Work Description: kinow commented on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-961461586
>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.
Exactly. Were it not for the `Imaging` public methods, we could use the
generics or any other design without much impact to users. But the current code
base uses `Imaging` as the main entry point for users in the API (unless users
want something more complicated, in which case they can use parsers directly.)
>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.
:+1: you described the problem really well!
>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
Ah, it sounds like a good thing to try! I think this approach would apply
some inversion of control, or algebraic effects, and could help us solve the
current impasse.
>Thoughts?
I think it would need a few more changes to allow users to configure the
correct parameter type? The `Consumer<ImagingParameters>` uses the base type,
so in this closure the user has only an instance of `ImagingParameters`, and
would have to cast to the correct type.
I used the last method in `Imaging.java` instead of `getIccProfileBytes`
(for convenience, to have the `main` method nearby in the IDE :grimacing: ):
```java
public static void writeImage(final BufferedImage src, final
OutputStream os,
final ImageFormat format, final Consumer<ImagingParameters>
configurer) throws ImageWriteException,
IOException {
final List<ImageParser> imageParsers =
ImageParser.getAllImageParsers();
ImageParser imageParser = null;
for (final ImageParser imageParser2 : imageParsers) {
if (imageParser2.canAcceptType(format)) {
imageParser = imageParser2;
break;
}
}
if (imageParser == null) {
throw new ImageWriteException("Unknown Format: " + format);
}
final ImagingParameters params = imageParser.getDefaultParameters();
configurer.accept(params);
imageParser.writeImage(src, os, params);
}
```
But the caller code still has issues with the parameter type, I think?
```java
public static void main(String[] args) throws Exception {
Imaging.writeImage(
(BufferedImage) null,
(OutputStream) null,
ImageFormats.TIFF,
(ImagingParameters p) -> { // if `TiffImagingParameters`:
Incompatible parameter types in lambda expression: expected ImagingParameters
but found TiffImagingParameters
// p is still ImagingParameters, not
TiffImagingParameters
p.setFileName("bla.tif");
});
}
```
Or would you re-write `writeImage` differently, @darkma773r ?
Thanks!
Bruno
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 676756)
Time Spent: 12h 50m (was: 12h 40m)
> 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 50m
> 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)
