FuncOf returning null on apply

[neonailol]

According to readme this library advertised and null-free

cactoos/README.md

Line 35 in 8586d83

* No `null` ([why?](http://www.yegor256.com/2014/05/13/why-null-is-bad.html))

But in FuncOf there is 2 constructors, that returns null on calling apply of retuned Func
Is this really nececary? Maybe they do not belong in there and should be moved to smth like FuncNlsOf or changed to better abstractions or simple removed

cactoos/src/main/java/org/cactoos/func/FuncOf.java

Lines 76 to 78 in 8586d83

	public FuncOf(final Proc<X> proc) {
	this(proc, null);
	}

cactoos/src/main/java/org/cactoos/func/FuncOf.java

Lines 68 to 70 in 8586d83

	public FuncOf(final Runnable runnable) {
	this((Proc<X>) input -> runnable.run());
	}

Also tests say that null is expected behaviour there

cactoos/src/test/java/org/cactoos/func/FuncOfTest.java

Lines 53 to 64 in 8586d83

	@Test
	public void convertsProcWithNoResultIntoFunc() throws Exception {
	final AtomicBoolean done = new AtomicBoolean(false);
	MatcherAssert.assertThat(
	new FuncOf<String, Boolean>(
	input -> {
	done.set(true);
	}
	).apply("hello you"),
	Matchers.nullValue()
	);
	}

cactoos/src/test/java/org/cactoos/func/FuncOfTest.java

Lines 66 to 75 in 8586d83

	@Test
	public void convertsRunnableIntoFunc() throws Exception {
	final AtomicBoolean done = new AtomicBoolean(false);
	MatcherAssert.assertThat(
	new FuncOf<String, Boolean>(
	() -> done.set(true)
	).apply("hello, world"),
	Matchers.nullValue()
	);
	}

Also i'm seeing same behaviour in constructors of CallableOf and BiFuncOf

[0crat]

@yegor256 please, pay attention to this issue

[llorllale]

@yegor256 I agree with this. Let us know if you differ

[llorllale]

@0crat in

[0crat]

@0crat in (here)

@llorllale Job #551 is now in scope, role is DEV

[0crat]

Bug was reported, see §29: +15 point(s) just awarded to @neonailol/z

[0crat]

The job #551 assigned to @SharplEr/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

[SharplEr]

@llorllale By the way, in case if all our objects are immutable then Proc<> have no sense. Proc<> can be used only for produce some side effects which are prohibited. I think it's okay to remove Proc<>. What do you think?

[llorllale]

@SharplEr what we are against is null. Be careful when removing that ctor - it's used in a number of places.

[yegor256]

@llorllale how can we fix that? I can't see any other solution...

[SharplEr]

@llorllale Okay. In case if I remove this ctor, it will affect about 15 other classes (tests included). So a big part of functionality will be lost. Do I need to save this functionality somehow?

[SharplEr]

@yegor256 I see one way, create new class:

FuncOptional<X, Y> implements Func<X,Optional<Y>>

Which can return Optional.empty() instead of null.

But unfortunately such code will not build:

public CallableOf(final Runnable runnable) {
    this(new FuncOptional<>(runnable));
}

Now I'm thinking about can I avoid this or not.

[llorllale]

@yegor256

how can we fix that? I can't see any other solution...

I believe we should drop this functionality all together because it goes against our principles and also simply because Func returns a value while Proc doesn't. To me, they're not conceptually compatible. If the user wants to return null then they are free to use the overload FuncOf<Proc<X> proc, Y value).

[llorllale]

@SharplEr although not stated as one of our principles, I know for a fact that @yegor256 doesn't like Optional.

I am personally not against Optional, but in this case the ready alternative for users is the FuncOf<Proc<T> proc, Y value) ctor.

[0crat]

@SharplEr/z this job was assigned to you 5days ago. It will be taken away from you soon, unless you close it, see §8. Read this and this, please.

[0pdd]

@neonailol the puzzle #861 is still not solved.

[SharplEr]

@neonailol PR was merged, please close the issue.

[SharplEr]

@0crat waiting
Waiting for author reaction.

[SharplEr]

@neonailol ping

[0crat]

@0crat waiting Waiting for author reaction. (here)

@SharplEr The impediment for #551 was registered successfully by @SharplEr/z

[0crat]

@elenavolokhova/z please review this job completed by @SharplEr/z, as in §30; the job will be fully closed and all payments will be made when the quality review is completed

[0crat]

The job #551 is now out of scope

[elenavolokhova]

@SharplEr According to our Policy:

Some of ticket messages must mention all pull requests where the problem was actually fixed;

There is no direct message with the link to corresponding PR.
Please, confirm that you will follow this rule in future.

[SharplEr]

@elenavolokhova confirm
PR was #843

[elenavolokhova]

@0crat quality acceptable

[0crat]

Order was finished, quality is "acceptable": +30 point(s) just awarded to @SharplEr/z

[0crat]

Quality review completed: +8 point(s) just awarded to @elenavolokhova/z

[0pdd]

@neonailol 6 puzzles #883, #884, #885, #886, #887, #888 are still not solved; solved: #861.

[0pdd]

@neonailol 5 puzzles #883, #884, #885, #886, #888 are still not solved; solved: #861, #887.

[0pdd]

@neonailol 4 puzzles #884, #885, #886, #888 are still not solved; solved: #861, #883, #887.

[0pdd]

@neonailol 4 puzzles #1040, #884, #885, #886 are still not solved; solved: #861, #883, #887, #888.

[0pdd]

@neonailol 3 puzzles #1040, #884, #886 are still not solved; solved: #861, #883, #885, #887, #888.

[0pdd]

@neonailol 3 puzzles #1040, #1062, #884 are still not solved; solved: #861, #883, #885, #886, #887, #888.

[0pdd]

@neonailol 2 puzzles #1040, #1062 are still not solved; solved: #861, #883, #884, #885, #886, #887, #888.

[0pdd]

@neonailol the puzzle #1040 is still not solved; solved: #1062, #861, #883, #884, #885, #886, #887, #888.

[0pdd]

@neonailol all 9 puzzles are solved here: #1040, #1062, #861, #883, #884, #885, #886, #887, #888.