Closed dietzc closed 7 years ago
Is this still applicable to the way we handle conversions now?
I'm actually not really sure. Do the following use-case swork?
Cell
of type A
.
ModuleInfo
requires primitive of type B
.
Converter
exists from A
->
B
.ModuleInfo
is C
CellFactory
extists for some D
and there exists a Converter
from C
to D
.Maybe we have to sneak the SciJava
Converter
s in (if they not already are...). I'm sure we don't need the OpMatchingService
directly.
Alright, just to make sure I undestand correctly:
- Use-Case Input: Input: Cell of DataType A. ModuleInfo requires Java Type (not primitive) of type B. KNIME Converter exists from DataType A -> B.
- Use-Case Output: Output of ModuleInfo is JavaType C KNIME Converter exists from C to some DataType D
Is that equivalent to what you wrote?
Maybe we have to sneak the SciJava Converters in (if they not already are...).
Yes, we should, and no, they aren't. KNIME Converter Framework only provides lossless conversions. Hence, there is no Converter to Byte
, since there is no ByteCell
, which provides sufficiently bad integer range (long and int would both lose "percision" during conversion). Same for Short
and Char
. We could append Scijava converters from the preferred value type of the cell in case no direct conversion is possible.
I think in SciJava also only loss-less Converter
s are supported. So this shouldn't be a problem at all. Correct me if I'm wrong @ctrueden.
It is planned to add support for both lossy and lossless converters in the ConvertService
, with API for calling either or both. And currently, the conceit is that conversion must always be lossless.
@Squareys please open a new, dedicated issue for this which doesn't involve Op
s.
ScijavaMatchingService
instead ofOpMatchingService
InputAdapters
andOutputAdapters