Groovy will automatically convert integers into objects, as it sees fit. And one such case is when you assign null to an integer.
There’s some more languages, which try to treat primitive types like objects, to make them more consistently usable. As I understand, nullability is a big part of the reason why it can’t be solved with syntactic sugar, so presumably this would be possible in all those languages.
If I’m not mistaken, Ruby is another one of those languages.
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.
Dark times…
Like -1 for an Int nil value.
Which language can nil an
int?Groovy will automatically convert integers into objects, as it sees fit. And one such case is when you assign
nullto an integer.There’s some more languages, which try to treat primitive types like objects, to make them more consistently usable. As I understand, nullability is a big part of the reason why it can’t be solved with syntactic sugar, so presumably this would be possible in all those languages.
If I’m not mistaken, Ruby is another one of those languages.
Groovy is pretty wild. It’s like, honey, you need me to make this a BigInteger for you? I got you honey, don’t even worry about it.
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.
Just cast it. /s
I believe, that would mean that any 0 is equivalent to the null pointer, since the null pointer is just memory address 0…
Not exactly “memory address 0”; there be dragons there. https://c-faq.com/null/index.html
In C that would make sense yes.
Probably some monad magic idk functional programming.