-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(#1335) Introduce NumberEnvelope and move number in their package #1587
Conversation
@@ -125,7 +125,7 @@ void withIterableOfInts() { | |||
void overflowIntFromLongValues() { | |||
MatcherAssert.assertThat( | |||
new SumOf(2_147_483_647L + 1L << 1, 10L).intValue(), | |||
new IsEqual<>(2_147_483_647) | |||
new IsEqual<>(10) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@svendiedrichsen I think you originally wrote this test, and I wasn't sure exactly what it was supposed to verify or test, but after changing the way SumOf is implemented, now it gives this result. Do you think this is correct and if not, could you help me understand why? thx!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@victornoel I have initially written this test to assure that long overflows during summation don't affect the result. Original commit here: cb97bf0#diff-68e784b552b842bf92ef1a42843f896862c82e87df36dcd69d8cd2561b1ad3b4
SumOf used to do summation using double values and thus being prone to overflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@svendiedrichsen thank you for your answer. I think the commit you linked to did not change: I was referring to the test this comment here is attached to. I understand the general why, I had seen the commits and messages, but for this particular test, I don't exactly understand why the previous behaviour is correct, and why this new one would not. If you have some insight about it, it would be really helpful :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@victornoel I can't remember anymore. Sorry. But if I had to guess. I think it is a test how the overflow is handled if you request an Int from a number larger than an int.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@svendiedrichsen ok, thanks :) I should find a satisfying solution I think, cheers
@0crat status |
@victornoel This is what I know about this job in C63314D6Z, as in §32:
|
fa754b6
to
5fd8103
Compare
@andreoss finally, this PR is ready to be reviewed. It's a bit big and I apologized for it, if it's too big, just tell me and I will have to break it into pieces, but if I can avoid it will be easier since there are both changes and moved classes :) |
* @since 1.0.0 | ||
*/ | ||
@SuppressWarnings("serial") | ||
@SuppressFBWarnings("SE_NO_SERIALVERSIONID") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@victornoel Why not add seriaId
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andreoss there are some implementation of number for which this do not make sense (the one based on 4 scalars mainly). IMHO EO and serializable classes does not make sense together.
That being said, your comment makes me think that maybe it's best to just leave serial id in case it makes sense :)
|
||
/** | ||
* Integer Scalar which sums up the values of other Scalars of the same type | ||
* Int total of numbers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@victornoel Bad renaming?
Matchers.equalTo(3) | ||
1, 2, 3, 4 | ||
), | ||
new AllOf<Number>(new IsEqual<>(2.5), new IsEqual<>(2.5)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@victornoel Should it be twice? Why not use IsNumber
https://github.com/llorllale/cactoos-matchers/blob/master/src/main/java/org/llorllale/cactoos/matchers/IsNumber.java
@andreoss thx, I took your comments into account |
Codecov Report
@@ Coverage Diff @@
## master #1587 +/- ##
============================================
- Coverage 90.16% 90.08% -0.09%
+ Complexity 1616 1603 -13
============================================
Files 302 298 -4
Lines 3784 3750 -34
Branches 121 122 +1
============================================
- Hits 3412 3378 -34
+ Misses 339 338 -1
- Partials 33 34 +1
Continue to review full report at Codecov.
|
51955aa
to
3cab66c
Compare
@0crat status |
1 similar comment
@0crat status |
@victornoel This is what I know about this job in C63314D6Z, as in §32:
|
@victornoel This is what I know about this job in C63314D6Z, as in §32:
|
@rultor merge |
@victornoel OK, I'll try to merge now. You can check the progress of the merge here |
@victornoel Done! FYI, the full log is here (took me 10min) |
Code review was too long (53 days), architects (@victornoel) were penalized, see §55 |
@sereshqua/z please review this job completed by @andreoss/z, as in §30; the job will be fully closed and all payments will be made when the quality review is completed |
@0crat quality good |
Last part of #1335: introduce NumberEnvelope and move all the Number implementations to their own packages.
Some tests were passing differently with respect to overflow and stuffs like that: I considered it was ok to change them, but I may have misunderstood their purpose. From my POV, they didn't bring anything particularly useful, but I will ask their original author in comments to review that.
This also covers #1591 and #1496 since they fitted nicely in this PR.