alt Hacker NewsI agree that there are better ways to model roles and FGA
the point of the example wasn't to be an idiomatic solution to that problem, but to illustrate the pointlessness of inheritance in general, and User Student Employee was the first thing that came to mind that was more "real" than the usual Animal examples
in any case, as for only having a User reference, you don't ever have only a User reference - overwhelmingly you would usually load a Student or Employee,
and each of them would have those attributes on them that characterize each of them respectively (and those attributes would not be shared - if they were, such shared attributes would go on the User object)
only those functions that truly are operating only on User would you send in each of their User objects
the problem with what you're advocating is you end up with functions like this
fun doSomething(user: User) { if (user is Student) { do this } else { do that } }
One example for when you might want something like a class hierarchy is something like a graph/tree structure, where you have lots of objects of different types and different attributes carrying references to each other that are not narrowly typed. You then have a set of operations that mostly do not care about the narrow types, and other operations that do care. You have things that behave mostly the same with small variations, in many cases.
> and each of them would have those attributes on them that characterize each of them respectively (and those attributes would not be shared - if they were, such shared attributes would go on the User object)
Suppose you want to compute a price for display, but its computation is different for Students and Employees. The display doesn't care if it's a Student or an Employee, it doesn't want to need to know if it's a Student or an Employee, it just wants the correct value computed. It can't just be a simple shared attribute. At some point you will need to make that distinction, whether it's a method, a conditional, or some other transform. It's not obvious how your solution could solve this more elegantly.
> which is insane
Not at all, in my view this kind of pattern matching is generally preferable over dynamic dispatch with methods, because you see what can happen in all cases, at a glance. But again, you do not even have a contrived example where you would need dynamic dispatch in the first place, so naturally its use not obvious.