4 ms·

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 de

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.
- noelwelsh 2y ago
  I'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 ago
    This is largely fair. Apologies I didn't make it clearer that my question here was specific to the example.

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.

noelwelsh 2y ago
I'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 ago
  This is largely fair. Apologies I didn't make it clearer that my question here was specific to the example.