GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||
GeezerVison is showing github.com — TestRunnerStatement with dynamic Parameter-list by pesse · Pull Request #96 · utPLSQL/utPLSQL-java-api Conversation
|
| } else if (i1 == null) { | ||
| return -1; | ||
| return nullMeansEqual ? 0 : -1; | ||
| } else if (i2 == null) { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Don't we need to check nullMeansEqual here so that comparetoWithNulls is symmetric?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't get it...
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't i2 be treated same way as i1 so that if i2 is null you check nullMeansEqual
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Ah.
I thought about this a lot yesterday. The thing is - we are not implementing the normal compareTo method, but we implement something which is only used by isGreaterOrEqualTo and isLessOrEqualTo.
For these 2 cases I think the comparison order is important, because the lazier "equal" depends on the base version to have a null.
Example:
Technically, when comparing 3.1.7 with 3.1.7.3085, 3.1.7 is less and not equal. That's how the comparison was before (null being treated as 0 basically).
But that's not what I want when using isGreaterOrEqualTo - I want this function to be forgiving if I only provide 3.1.7 as base, so any number in the 4th level of the comparison should be treated as being equal.
On the other hand, when I provide a specific base (e.g. 3.1.7.3085), I really expect it to be precise, so I can't treat i2 the same way in that case.
Maybe I should not use parameters here and instead write the isGreaterOrEqualTo function separately so it's more clear we're not implementing a strict compareTo here.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
Different FileMapper call 3.0.0 to 3.0.2
There was an error while loading. Please reload this page.