Yeah let’s use a union of a boolean and null to represent role, something that inherently represents more than two (…or three, I guess) different values, as opposed to something like an integer.

Even if the name is clearly misleading in this specific case, the entire choice of using a bool here is just bad because it’s almost guaranteed you’re going to expand on that in future and then you’ll just have to entirely rewrite the logic because it simply can’t accommodate more than two values (or three with the null union… 🙈), while it gives absolute zero benefits over using something more reasonable like an integer to represent the roles, or in this case, admin, not-admin and guest. Even if you’ll end up with just admin, non-admin and guest, the integer would still work great with no disadvantages in terms of amount of code or whatever. Just increased legibility and semantical accuracy.

Not to mention that there’s zero reason to combine the state of being logged in and the role in which you’re logged in in one variable… those are two different things. They will remain two different things in future too…

I mean they’re already chaining elseifs (basically matching/switching, while doing it in an inefficient way to boot 🥴) as though there were an n amount of possible states. Why not just make it make sense from the start instead of whatever the hell this is?

[–] dev_null@lemmy.ml 5 points 16 hours ago (7 children)

This is quite reasonable, aside from the variable name which should be isAdmin. A user either is an admin, or isn't. Unless we don't know, then it's null. You are correct this is bad if the point was to represent roles, but it's not supposed to.

[–] orgrinrt@lemmy.world 1 points 14 hours ago (6 children)

Admin is a role though, was my point. And besides, if you check for three different states, and you decide to go with a boolean to represent that, I really find it hard to believe anyone would think it reasonable. It’s valid and it’s practical, but can you really say it’s reasonable?

I don’t do typescript, but wouldn’t a union of a null and a bool be just more resource intensive than simply using an unsigned byte-sized integer? I struggle to find reasons to ever go for that over something more reasonable and appropriate for what it attempts to represent (3 distinct states as it stands, and likely in future more than just 3 when they have a need for more granularity, as you’d often do with anything you’d need an admin role distinction in the first place), but likely I’m just not familiar with ts conventions. Happy to hear the reasoning for this though.

[–] dev_null@lemmy.ml 1 points 14 hours ago* (last edited 14 hours ago) (1 children)

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.

[–] orgrinrt@lemmy.world 2 points 12 hours ago* (last edited 12 hours ago) (1 children)

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.

[–] dev_null@lemmy.ml 1 points 7 hours ago* (last edited 7 hours ago) (1 children)

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.

[–] orgrinrt@lemmy.world 1 points 2 hours ago

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.

load more comments (4 replies)