4 ms·
Name and Password are probably going to wrap the String type. Admin and Normal don't have data associated with them. They are just flags (or tags, depending on
by noelwelsh 2y ago
Name and Password are probably going to wrap the String type. Admin and Normal don't have data associated with them. They are just flags (or tags, depending on the terminology you are used to.)
So when we write
User = (Name x Password x Normal) + (Name x Password x Admin)
we know that Normal and Admin distinguish two otherwise identical cases. So with a bit of substitution we can write
User = Normal + Admin
Normal = (Name x Password)
Admin = (Name x Password)
True + False is isomorphic to Normal + Admin, but if you aren't used to working in a language with algebraic data types you might not be used to thinking in this way.
In Haskell you'd write something like
data User = Normal Admin Password | Admin Name Password
You could equally write
data User = True Admin Password | False Name Password
because True and False are just tags, distinct from their use in the boolean type. This would just really confusing to other programmers.
- taeric 2y agoI had a jest, at one point, where I would assume you are not modeling a password in your system. :D I'm assuming you'd instead model an AuthenticatedUser or some such. To that end, I'm fine with giving leeway to the modeling here. We are going for pedagogy. To that end, if this is a matter of going fast due to constraints of a message board, I am fine. My specific confusion was at the start where you had `Admin = Name x Password`. I'm not at all clear on what that would communicate to me in the types of any variables I would have in my code.
- noelwelsh 2y agoHave you used a language with algebraic data types? I assumed some familiarity, and also with the terminology sum and product types. Admin = Name x Password defines a type called Admin that has a Name and a Password. In OCaml I would write something like type Admin = Name * Password In Scala I'd write final case class Admin(name: Name, password: Password) The construction User = Normal + Admin Normal = (Name x Password) Admin = (Name x Password) in words is: A User is Normal or Admin A Normal (User) is a Name and a Password An Admin (User) is a Name and a Password In Scala enum User: case Normal(name: Name, password: Password) case Admin(name: Name, password: Password) In OCaml type User = Normal of Name * Password | Admin of Name * Password
- taeric 2y agoThis all makes sense, at a basic pass. But what does it tell me to claim that an Admin is a Name and a Password? (It probably doesn't help that I'm used to role based permissions where you will emphatically not have a name associated with the authorization. You should be able to trace it back to an authentication, which will have a name, but those are different.) I'm also confused with these assertions, as with this formulation, you make it far too easy to think that a User is an Admin. Due to the norm for equality rules being that they are transitive. Again, if this is just a shortcoming of this particular example, I'm fine with that. I am not trying to tear down the whole idea over the example. I literally just don't understand what it would mean for my model to say that an admin is a name and a password. Transitively, that feels very dangerous when considered in the way I'm used to modeling authentication and authorization.
- noelwelsh 2y agoI'm just trying to make an allusion to how people might model the data in a simple CRUD app. I think you're getting too concerned with the details wrt your prior experience. Make it Pet = Name x Weight x Species, and Species = Dog + Cat if you prefer.
- taeric 2y agoThis is largely fair. Apologies I didn't make it clearer that my question here was specific to the example.