[API-8] Improve Tristate

[ItsDoot]

Adds:

• Tristate#not
• Tristate#fromNullableBoolean
• Tristate#asNullableBoolean

[Zidane]

Maybe call it negate?

[ItsDoot]

Edited

[ST-DDT]

Maybe also change the method name accordingly?

[ItsDoot]

IMO not lines up better with and/or than negate does.

[dualspiral]

Looks okay, I think a method needs renaming and one should be added for consistency.

[dualspiral]

I feel like this should be named fromNullableBoolean.

If we have this, should we also have an asNullableBoolean analogue?

[ItsDoot]

See, I was thinking about doing asNullableBoolean, but what should it return? Returning an actual nullable boolean would make sense, but Sponge prefers Optionals... which to me would feel a little weird.

[dualspiral]

This is one of those rare cases I'd have a nullable return type as a one-to-one mapping of Boolean<->Tristate - if you can get a Tristate from a Boolean, it stands to reason that you should be able to go the other way just as simply.

I'll let @Zidane call this one, but I think it should just be a @Nullable Boolean return type. There is an extra clue in the name of the method here, if you're not expecting the possibility of it being null if you grab the Boolean then that's really your lookout.

[ST-DDT]

I would prefer, not to have a asNullableBoolean, because this class is the replacement for the nullable/unset boolean.

As for the fromX methods, I would rather name them both from (or fromBoolean) with just different parameters. Let the compiler decide which one it should use.

[dualspiral]

because this class is the replacement for the nullable/unset boolean.

That doesn't change my argument at all. I'm saying the mapping should work both ways in case you then interact with some system that isn't Tristate aware - plugins can (and often do) work with third party libraries.

[ItsDoot]

Changed fromNullable to fromNullableBoolean, and added asNullableBoolean.

As for the fromX methods, I would rather name them both from (or fromBoolean) with just different parameters. Let the compiler decide which one it should use.

@ST-DDT I'd rather users explicitly opt-in to using the nullable boolean conversions. Then it's clear when someone else is reading your code, for example.

[ST-DDT]

While we are at it we should also change:

SpongeAPI/src/main/java/org/spongepowered/api/util/Tristate.java

Lines 33 to 37 in d042657

	TRUE(true) {
	@Override
	public Tristate and(Tristate other) {
	return other == TRUE || other == UNDEFINED ? TRUE : FALSE;
	}

to

return other == FALSE ? FALSE : TRUE;

This is shorter/easier to understand and also matches the FALSE#or(...) style.

[ItsDoot]

Agreed @ST-DDT