4 ms·

Or is + (Writing or was a typo) User has a Name, Password, and a Role, which gives User = Name x Password x Role Role is Normal or Admin. Formally: Role

Or is + (Writing or was a typo) User has a Name, Password, and a Role, which gives User = Name x Password x Role Role is Normal or Admin. Formally: Role = Normal + Admin Now substitute User = Name x Password x (Normal + Admin) Multiply out User = (Name x Password x Normal) + (Name x Password x Admin) I added an extra step where I named some of the components. If you understand how this can be represented in code as an algebraic data type, you will see these two different representations have different properties when you come to program with them. If you don't, I'm afraid this text box does not contain enough space. Chapter 2 of https://scalawithcats.com/ https://scalawithcats.com/ goes through this in much more detail.

taeric 2y ago
Cool, was curious why you had + and "or". I was assuming both are the same as | in the linked article. (I am further assuming you are largely working on the "left hand side" per the article?) The rest of your math, I largely followed, but I can't see where `Normal = Name x Password` results. Nor do I see what it would communicate. This is why I dropped instead to Boolean = True | False. If I substitute that in your statements, I get `True = Name x Password`. And I don't see how that means anything. :(
- 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 ago
    I 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 ago
      Have 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 ago
        This 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.

taeric 2y ago

Cool, was curious why you had + and "or". I was assuming both are the same as | in the linked article. (I am further assuming you are largely working on the "left hand side" per the article?) The rest of your math, I largely followed, but I can't see where `Normal = Name x Password` results. Nor do I see what it would communicate. This is why I dropped instead to Boolean = True | False. If I substitute that in your statements, I get `True = Name x Password`. And I don't see how that means anything. :(

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 ago
  I 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 ago
    Have 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 ago
      This 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.