So in a language with nullable types, are you against a boolean ever being nullable? Null means “empty, missing info”. Let’s say we have role variable with a enum type of possible roles. It could still reasonably be nullable, because in some scenarios you don’t know the role yet, like before log in.
In any use case where we need to store some boolean, it’s a common occurrence that we don’t have the data and it’s null. It would be overkill to use an enum with True, False, NoData for these cases, where there is already a language feature made just for that, nullable values.
I’ve never used TypeScript, just writing from experience in other languages.
Yeah, but if it is about being an admin or not, hence the bool, it’d be idiomatic and reasonable to assume it to be false if we have no data. Unless we want to try and allow admin access based on no data. Having three states for a simple binary state is weird. And if it is not about just being an admin or not, the bool is inherently a too limited choice for representation.
If the admin status needs to be checked in a database, but most actions don’t require authentication at all, it’s pointless to waste resources checking and it would be left null until the first action that needs the information checks it and fills it in as true or false.
I don’t really follow you there, wouldn’t it be exactly the opposite and wouldn’t checking for nulls be, as a premise, more wasteful? But doesn’t really matter, time to digress. I’m conventionally educated as an engineer so what I know and find reasonable today might be outdated and too strict for most contemporary stuff.
Let’s say you have a website receiving 1 million requests per day. 0.01% of those are admin requests that need to know if your are an admin to execute them. It would be wasteful to check with the database if you are an admin for every request, when only a tiny minority of then needs to know that. So for 999.900 of the requests isAdmin will be null. We don’t know if the user is an admin and we don’t need to know.
That all is besides the point. There’s no real advantage to use null instead of defaulting to false there… it’s semantically more accurate and also less wasteful in that other code does not have to worry about nulls which always leads to unnecessary overhead when false is already equivalent in your proposed example.
It is not more accurate nor less wasteful. If you default it to false and you have 100 admin requests in the session where that variable is stored, you would have to check with the database 100 times. Because you are conflating false to mean two things: “the user is not an admin” and “we don’t know if the user is an admin”. Where if you set it to true or false the first time we need the information, then subsequent requests don’t need to check anymore.
does not have to worry about nulls
I am used to null safe languages where there is no such thing as worrying about nulls, because not checking for null on a nullable type is a compile error, and so it’s impossible to forget about the null case. Maybe it’s why I don’t see any issue with using them.
So in a language with nullable types, are you against a boolean ever being nullable? Null means “empty, missing info”. Let’s say we have
rolevariable with a enum type of possible roles. It could still reasonably be nullable, because in some scenarios you don’t know the role yet, like before log in.In any use case where we need to store some boolean, it’s a common occurrence that we don’t have the data and it’s null. It would be overkill to use an enum with
True,False,NoDatafor these cases, where there is already a language feature made just for that, nullable values.I’ve never used TypeScript, just writing from experience in other languages.
Yeah, but if it is about being an admin or not, hence the bool, it’d be idiomatic and reasonable to assume it to be false if we have no data. Unless we want to try and allow admin access based on no data. Having three states for a simple binary state is weird. And if it is not about just being an admin or not, the bool is inherently a too limited choice for representation.
Depends on your requirements.
If the admin status needs to be checked in a database, but most actions don’t require authentication at all, it’s pointless to waste resources checking and it would be left null until the first action that needs the information checks it and fills it in as true or false.
I don’t really follow you there, wouldn’t it be exactly the opposite and wouldn’t checking for nulls be, as a premise, more wasteful? But doesn’t really matter, time to digress. I’m conventionally educated as an engineer so what I know and find reasonable today might be outdated and too strict for most contemporary stuff.
Let’s say you have a website receiving 1 million requests per day. 0.01% of those are admin requests that need to know if your are an admin to execute them. It would be wasteful to check with the database if you are an admin for every request, when only a tiny minority of then needs to know that. So for 999.900 of the requests
isAdminwill benull. We don’t know if the user is an admin and we don’t need to know.That all is besides the point. There’s no real advantage to use null instead of defaulting to false there… it’s semantically more accurate and also less wasteful in that other code does not have to worry about nulls which always leads to unnecessary overhead when false is already equivalent in your proposed example.
It is not more accurate nor less wasteful. If you default it to
falseand you have 100 admin requests in the session where that variable is stored, you would have to check with the database 100 times. Because you are conflatingfalseto mean two things: “the user is not an admin” and “we don’t know if the user is an admin”. Where if you set it totrueorfalsethe first time we need the information, then subsequent requests don’t need to check anymore.I am used to null safe languages where there is no such thing as worrying about nulls, because not checking for null on a nullable type is a compile error, and so it’s impossible to forget about the null case. Maybe it’s why I don’t see any issue with using them.