search

imagej / imagej-ops

ImageJ Ops: "Write once, run anywhere" image processing
https://imagej.net/libs/imagej-ops
BSD 2-Clause "Simplified" License
89 stars 42 forks source link

Problem(?) with the matcher #374

Open dietzc opened 8 years ago

dietzc commented 8 years ago

see: https://github.com/imagej/imagej-ops/tree/strange-matcher.

The problem is related to the canCast method in https://github.com/imagej/imagej-ops/blob/master/src/main/java/net/imagej/ops/DefaultOpMatchingService.java#L267.

lnyng commented 8 years ago

UnaryHybridAF when treated as a Function op, IT guarantees to return some kind of Fruit, but not specifically which kind. Therefore, when you ask for a UnaryHybridAF that takes an Apple and returns an Apple, it does not match. Thinking about that, it could potentially returns a Lemon to you!

However, when it is treated as a computer, right now we do not check if the output matches (see the null here, that's the output type). This is because the return mechanism for Computer and Function are different - Computer works fine as long as YOU guarantees that the given is some kind of Fruit. The op does not care whether if the output is Apple or Lemon or Orange.

Does this make sense? @ctrueden please point out if I am wrong.

ctrueden commented 8 years ago

I still haven't had time to look at or think much about this. Will try to do so soon, as part of the generics-insanity op matching rework. The main issue with generics compatibility when matching is that there is a critical difference between "there exists" and "for all". My (weak) intuition is that this problem with the matcher is impacting the matching in this scenario. Will follow up more later.