Comment by mrkeen | Hacker News Reader

Comment by mrkeen | Hacker News Reader

Parent Full thread

I regret shooting from the hip, and answering the comment directly rather than tying it back to the article.

String->(valid)Email is 'Parse', (invalid)Email->ValidEmail is 'Validate'.

> That way you never have to guess whether the email adress is unchecked

Now you just get to guess whether, for every class, there is actually a ValidClass that you were supposed to be using, instead of Class.

  authenticate(User user);

^ This is a bug. We just let a malicious User object in because we invested extra time, effort and sloc into making both a User and a ValidUser class, disregarding the first "simple idea" from the article:

>> 1. Use a data structure that makes illegal states unrepresentable

Or as I wrote:

> only make classes for valid objects

> Now you just get to guess whether, for every class, there is actually a ValidClass that you were supposed to be using, instead of Class.

The type system stops this. You can't pass, e.g. a User to authenticate because it only accepts a ValidUser.

> only make classes for valid objects

Using primitives (String, Int, etc.) for unvalidated input, and custom classes for validated input is fine in many cases. However, sometimes you need to represent data that is in the process of being validated (e.g. when validation takes time, like waiting for a user to validate their email address) and then these intermediate classes arrive.

I think, for most cases with partial validation, you should parse the fields first into valid types for those fields and store them in a hashmap or something. When all the fields have been collected, parse the hashmap into your aggregate type.

But your colleage just implemented it with User - because he could

No tool can fully protect against user incompetence (pun intended). You can have the fanciest type system in the world and still implement everything as a String, for example.

Reply on news.ycombinator.com