Assertion.java:111-115: Avoid the overloading ctor to...

[0pdd]

The puzzle 53-0c767106 from #53 has to be resolved:

cactoos-matchers/src/main/java/org/llorllale/cactoos/matchers/Assertion.java

Lines 111 to 115 in 84e2fb9

	* @todo #53:30min Avoid the overloading ctor to accept subtype.
	* Throws is a Matcher and thus there should be no need to give it a
	* special treatment. The fact that we're currently being forced to do so
	* smells, and might mean we may end up having to rethink these
	* abstractions.

The puzzle was created by @dgroup on 21-Jan-19.

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

[0pdd]

This puzzle inherited milestone 1.0.0 from issue #53.

[0crat]

@llorllale/z please, pay attention to this issue

[0crat]

Job #88 is now in scope, role is DEV

[0crat]

The job #88 assigned to @longstone/z, here is why; the budget is 30 minutes, see §4; please, read §8 and §9; if the task is not clear, read this and this; there will be no monetary reward for this job

[longstone]

@0crat wait
The way the implementation is done creates an impediment. I see the following ways

1. leave it as it is
2. create an AssertException class
3. rebuild the complete mechanism and let exceptions happen during the evaluation and check then if they're expected. this would lead to a lot of new puzzles, I assume.

@llorllale: what is the prefered approach?

[0crat]

@0crat wait The way the implementation is done creates an impediment. I see the following ways ... (here)

@longstone The impediment for #88 was registered successfully by @longstone/z

[llorllale]

@longstone none of the above?

I don't have an answer for you, sorry.

[victornoel]

@longstone see the discussion here too #106 (comment)

I think things are kind of overcomplicated for nothing.

If it is necessary to keep the Scalar<T> argument of Assertion, then we should simply have this kind of usage of:

        final AtomicInteger quantity = new AtomicInteger(0);
        new Assertion<Scalar<Text>>(
            "scalar throws the exception",
            () -> () -> {
                quantity.incrementAndGet();
                throw new IllegalStateException("this is a test");
            },
            new Throws<>("this is a test", IllegalStateException.class)
        ).affirm();

But I think it would be simply nicer to just have Assertion take a T.

[victornoel]

@longstone for the record, after discussing it in #106, we concluded that the best solution was the one outlined here: #106 (comment)

@llorllale by the way, it seems @longstone stopped working on this…

[llorllale]

@0crat refuse

[llorllale]

@0crat assign me

[0crat]

@0crat refuse (here)

@llorllale The user @longstone/z resigned from #88, please stop working. Reason for job resignation: Order was cancelled

[0crat]

@0crat assign me (here)

@llorllale The job #88 assigned to @llorllale/z, here is why; the budget is 30 minutes, see §4; please, read §8 and §9; if the task is not clear, read this and this; we should be aware that @llorllale/z is on vacation; this ticket may be delayed; there will be no monetary reward for this job

[0crat]

Manual assignment of issues is discouraged, see §19: -5 point(s) just awarded to @llorllale/z

[llorllale]

@0crat wait I submitted PR #109 for this

[0crat]

@0crat wait I submitted PR #109 for this (here)

@llorllale The impediment for #88 was registered successfully by @llorllale/z

[0pdd]

The puzzle 53-0c767106 has disappeared from the source code, that's why I closed this issue.

[0pdd]

@0pdd the puzzle #110 is still not solved.

[0crat]

The job #88 is now out of scope

[0crat]

Order was finished: +30 point(s) just awarded to @llorllale/z

[0pdd]

@0pdd the puzzle #113 is still not solved; solved: #110.

[0pdd]

@0pdd the puzzle #116 is still not solved; solved: #110, #113.

[0pdd]

@0pdd all 3 puzzles are solved here: #110, #113, #116.