gakuzzzz/0_.md

Last active May 20, 2021 10:32

Star (0) You must be signed in to star a gist
Fork (0) You must be signed in to fork a gist

Select an option

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/gakuzzzz/6acd31a9c7d1756ae6c2745442720a79.js"></script>
Save gakuzzzz/6acd31a9c7d1756ae6c2745442720a79 to your computer and use it in GitHub Desktop.

Download ZIP

YAVI に Applicative な Validation 入れるよの話

Raw

0_.md

making/yavi#121

Validator に (validateToEither と同様な) validateToAp みたいなのを作らず ApplicativeValidator を別に用意したのは何故なんでしょう？
- validateToValidation みたいな謎な名前になってしまうから？
ApplicativeBuilder的な ComposingN があるので FunctionN に curried を持たせなくても良さそうですね（実装は泥臭くなりますがオブジェクト生成数を抑制できます）
- 逆にカリー化できる関数があると ComposingN のようなものを不要にできたりもします。
- とは言えYAVIのユースケースだと Validator からメソッドチェーンで使うのが主だと思うので、ComposingN の方が有用そうですね。
- 完全に余談ですが、カリー化できる FunctionN を別途定義するより、curried を static メソッドにすると curried(Foo::bar) みたいな使い方が可能になるので個人的にはそちらの方がお勧めです。（Functions 的な1クラスのoverloadですませられますし）
Validation<E, > の apply が Validation<List<E>, > を返すのがびっくりしますね。Applicative の挙動を期待するなら型としては Validation<E, > になるので。
- YAVI の利用範囲から考えると、エラーの集約方法を汎用化する必要もなさそうなので、error は最初から List に決め打ちしちゃってもいいかもしれません。以下のようなイメージです。
- ```
public interface Validation<E, T> extends Serializable {
    boolean isValid();

    T value();
    List<E> error();
...
```
- 名前があれであれば ValidationNel とか ValidationL とか？
- 元のコードで Validation<ConstraintViolations, > だったものも ValidationL<ConstraintViolation, > にするイメージですね。

せっかく Applicative な結果ができたので sequence / traverse が欲しくなりますね。

Validator<Email> emailValidator = ValidatorBuilder.of(Email.class)
                                                    .constraint(...)
                                                    .build()
                                                    .prefixed("email");
List<Email> mails = List.of(...);

ValidationL<ConstraintViolation, List<Email>> validated = 
    ValidationL.traverse(mails, emailValidator.applicative()::validate);

List に特化するよりは Collector化してStreamにできる全コンテナに対応してもいいかもです。参考 https://gist.github.com/gakuzzzz/0c779d5335f4b2bff596#traverse-%E3%81%A8-sequence

本筋とは関係ないですが様々なところで上限境界や下限境界を使ってないのは意図的なんでしょうか？

making commented May 13, 2021

ApplicativeValidator.validate()の返り値を次のような特化型Validationにして、ConstraintViolationsを返すようにしてみます。

package am.ik.yavi.core;

import am.ik.yavi.fn.Validation;

/**
 * A specialized {@code Validation} class that regards {@code ConstraintViolation} as failure type
 * @param <T> value type in the case of success
 * @since 0.6.0
 */
public class Validated<T> implements Validation<ConstraintViolation, T> {
	private final Validation<ConstraintViolation, T> delegate;

	public static <T> Validated<T> of(Validation<ConstraintViolation, T> delegate) {
		return new Validated<>(delegate);
	}

	Validated(Validation<ConstraintViolation, T> delegate) {
		this.delegate = delegate;
	}

	@Override
	public boolean isValid() {
		return delegate.isValid();
	}

	@Override
	public T value() {
		return delegate.value();
	}

	@Override
	public ConstraintViolations error() {
		return new ConstraintViolations(delegate.error());
	}
}

自分の知識だとfoldやmapErrorをConstraintViolationsに特化できなかったので、いったんValidation<ContraintViolation, T>に戻します...
こういうオーバーライドがしたかったが、できなかった。

	@Override
	public <U> U fold(Function<ConstraintViolations, U> errorsMapper, Function<T, U> mapper) {
		// ...
	}

	@Override
	public <E2> Validation<E2, T> mapErrors(Function<ConstraintViolations, List<E2>> errorsMapper) {
		// ...
	}

making commented May 13, 2021

ValidationL<ConstraintViolation, List> validated = ValidationL.traverse(mails, emailValidator.applicative()::validate);

traverseでConstraintViolationを集約した場合、ConstraintViolationにmailsのindexをfieldNameに含めたくなりますね。indexを受けるlamdaも渡さないと実用的ではない気がする...

making commented May 13, 2021

完全に余談ですが、カリー化できる FunctionN を別途定義するより、curried を static メソッドにすると curried(Foo::bar) みたいな使い方が可能になるので個人的にはそちらの方がお勧めです。（Functions 的な1クラスのoverloadですませられますし）

試してみます。

making/yavi@8f85fcd
staticメソッドにしました。