Just thinking... maybe it would be a good idea to ...
# akkurate
d
Just thinking... maybe it would be a good idea to have a variant of
Validator { }
that generates a
Raise<NonEmptySet<ConstraintViolation>>.() -> T
that way it could be used in an either without
toEither()
and
bind(..)
?
d
Well, that's the same idea more-or-less, but it would be nice if we could avoid the toEither/bind altogether and just have a lambda returning the value being validated or Raising with violations... but I guess that could be complex to implement? I made a mistake in the question, I meant:
Raise<NonEmptySet<ConstraintViolation>>.() -> T
where
T
is the entity being validated...
j
Sorry for the delay, I did not check my messages these last days. I'm not really fond of the
Validator { }
variant for Arrow, because it will create a new declaration with a weird name like
ArrowValidator
and it would also duplicate the interface by changing its return types. The idea suggested by Alejandro seems to be a better fit: the
validate
function keeps the same name, regardless of the context (within a
Raise
computation or not) ; and the interface doesn't change since it returns the same type but the
validate
function does the work to bind the value to the
Raise
computation.
d
Yeah, I know it would have been complex to do that... but I can't help thinking how ValidationResult is really just a simplified Either type... w/o all the features. I guess Alejandro's proposition is easier and would still do the trick, with a few more object allocations... just the naming bothers me a bit... it's a bit inconsistent to replace validator { } with akkurate {} just for the Arrow adapter...
j
Oh I linked the original message, not the specification, here it is: https://github.com/users/nesk/projects/1/views/1?filterQuery=-is%3Aclosed+inline&amp;pane=issue&amp;itemId=46921332 In it, you will find up-to-date informations, with proper naming 🙂
but I can't help thinking how ValidationResult is really just a simplified Either type...
you're right, but not everyone uses Arrow, I don't want Akkurate to have a hard dependance on it
d
I find it funny that:
Copy code
val validatedUsername = validate(username) {
        isNotBlank()
    }
doesn't create a validator that can be reused to validate multiple times like the main api, but rather validates on the spot?
j
that's right, I'm not sure about this honestly 😄
this is only a proposal
d
I would have maybe expected this:
Copy code
val usernameValidator = validate(username) {
        isNotBlank()
    }

... either {
   val username = usernameValidator(...)
   ...
}
But the usernameValidator would have Raise<ConstraintViolations> as it's receiver...
j
I'm not sure if this is something possible 🤔 Maybe with extension functions
I'll have a look