Yeah, I kind of respect the stance, because it knows what it wants to be, but I also wrap number types into a separate data type to document that maybe you shouldn’t multiply a port number by the wheel count and pass that into the temperature parameter, because I want more fine-grained typing, not one-size-fits-all.
I think that somewhat reflects the “parse, don’t validate” advice I found somewhere. I’ll look for the link and edit if I find it (edit: I did!) but the idea is something like “when a value first enters your code, parse it into a type / struct the rest of your code proceeds to use”. That way, you check “does this make sense as a port number?” exactly once, throw it right back at the source if it doesn’t, put a “yep, this fits” stamp on it if it does and never worry about it again, thus saving repetitive boilerplate code.
It’s definitely part of the reason why I like these really narrow types. But the other big reason is that your internal APIs start to look like this:
It just makes it almost impossible to pass the wrong value into a parameter. You don’t need to wonder, whether you should pass your port variable into a parameter called bind_port, if you introduced separate types BindPort and RemotePort for them.
Of course, this is a somewhat extreme example. It’s up to you to decide, whether you’re likely to encounter multiple values of the same type and whether it’s therefore helpful to make it impossible to confuse them.
oooor you could just stuff it all in the square hole 😁
But seriously, I like the approach. I tend to go overboard with my type definitions sometimes, because I feel like it saves me some thinking down the line, and conversely get frustrated when the tools for it are limited.
My first foray into the world of programming was a python book for kids. Among other things, it featured an example for multi-line strings that contained the line “Explicit is better than implicit”. Aside from the irony of quoting that in the context of python (I believe it was written for 2.4 or 2.5, before explicit typing was even supported), it stuck with me.
Yeah, I kind of respect the stance, because it knows what it wants to be, but I also wrap number types into a separate data type to document that maybe you shouldn’t multiply a port number by the wheel count and pass that into the temperature parameter, because I want more fine-grained typing, not one-size-fits-all.
I think that somewhat reflects the “parse, don’t validate” advice I found somewhere. I’ll look for the link and edit if I find it (edit: I did!) but the idea is something like “when a value first enters your code, parse it into a type / struct the rest of your code proceeds to use”. That way, you check “does this make sense as a port number?” exactly once, throw it right back at the source if it doesn’t, put a “yep, this fits” stamp on it if it does and never worry about it again, thus saving repetitive boilerplate code.
Ah, yeah, very familiar with that article. 🙃
It’s definitely part of the reason why I like these really narrow types. But the other big reason is that your internal APIs start to look like this:
It just makes it almost impossible to pass the wrong value into a parameter. You don’t need to wonder, whether you should pass your
portvariable into a parameter calledbind_port, if you introduced separate typesBindPortandRemotePortfor them.Of course, this is a somewhat extreme example. It’s up to you to decide, whether you’re likely to encounter multiple values of the same type and whether it’s therefore helpful to make it impossible to confuse them.
oooor you could just stuff it all in the square hole 😁
But seriously, I like the approach. I tend to go overboard with my type definitions sometimes, because I feel like it saves me some thinking down the line, and conversely get frustrated when the tools for it are limited.
My first foray into the world of programming was a python book for kids. Among other things, it featured an example for multi-line strings that contained the line “Explicit is better than implicit”. Aside from the irony of quoting that in the context of python (I believe it was written for 2.4 or 2.5, before explicit typing was even supported), it stuck with me.
I love the idea of “tiny types” like that and wish they were built into more languages.