4 ms·
Yeah, but I think it's even more so, they're arguing that you should model the fact that something has been validated or not, and functions should indicate if t
by didibus 5y ago
Yeah, but I think it's even more so, they're arguing that you should model the fact that something has been validated or not, and functions should indicate if they expect a validated form of input or not.
In that sense, using types is only one way to do this, but you could model that in other ways. For example:
var foo = "123"
foo = validFoo(foo)
print(foo)
> {"value" : "123",
"valid?" : true}
And now you could have:
function bar(validFoo) {
if (!validFoo.get("valid?"))
throw new InvalidInputException("Foo must be validated prior to calling bar.")
...
}
Now types are a convenient way to do this that also gives you static checking for it, but I believe the idea is more to model that things were validated and expects validated input or fail.
That allows you to push all validation at the boundary, and make sure that no one ever forgets to validate the input, because if they do, the inner functions will fail reminding the caller: Please remember to validate this!
- billytetrud 5y agoMakes sense. It just seems like parsing is kind of a separate issue and shouldn't be entangled with the concept of input validation.
- Iazel 5y agoInteresting, would you mind explaining why parsing and validation are two different concerns?
- billytetrud 5y agoWhen I think of "parsing" I'm thinking of string parsing. But for example, validation of a number being in range or an obect containing a correct set of properties is not in the realm of string parsing, but is in the realm of validation.