Remember: federal power is delegated from the states, not the other way around.
At the top of the Articles, it's pretty clear that the delegates of the states have come together to establish a league of states. At the top of the Constitution, it's explicitly stated that "We the People […] do ordain and establish."
The Rawlsian veil ethic applies here.
EDIT: RE - the knee-jerk downvotes. I appreciate that people pointing out authoritarianism can be painful if you are embracing it. Cognitive dissonance is never a fun thing to work through, and having done it a few times I sympathize with the struggles you face or may be facing.
As someone who came legally to Canada and went through thorough screening of 4 years before coming I just don’t get how people are ok with “cheaters” gaming the system.
“Think of the children” works when you are in a super white rich neighborhood, if you never lived in slums you won’t understand the abuse of the system by “think of the children”, you just don’t see it from the other side.
"Make bank. Troll the libs." The people behind this see it as a win-win.
Deep breaths, people. Deep breaths.
Don't ever use inheritance. Instead of things inheriting from other things, flip the relationship and make things HAVE other things. This is called composition and it has all the positives of inheritance but none of the negatives.
Example: imagine you have a school system where there are student users and there are employee users, and some features like grading that should only be available for employees.
Instead of making Student and Employee inherit from User, just have a User class/record/object/whatever you want to call it that constitutes the account
data class User (id: Int, name: String, email: String)
and for those Users who are students, create a Student that points to the user data class Student (userId: Id, blabla student specific attributes)
and vice versa for the Employees data class Employee (userId: Id, blabla employee specific attributes)
then, your types can simply and strongly prevent Students from being sent into functions that are supposed to operate on Employees etc etc (but for those cases where you really want functions that operate on Users, just send in each of their Users! nothing's preventing you from that flexibility if that's what you want)and for those users who really are both (after all, students can graduate and become employees, and employees can enroll to study), THE SAME USER can be BOTH a Student and an Employee! (this is one of the biggest footguns with inheritance: in the inheritance world, a Student can never be an Employee, even though that's just an accident of using inheritance and in the real world there's actually nothing that calls for that kind of artificial, hard segregation)
Once you see it you can't unsee it. The emperor has no clothes. Type-wise functional programmers have had solutions for all these made up problems for decades. That's why these days even sane Object Oriented language designers like Josh Bloch, Brian Goetz, the Kotlin devs etc are taking their languages in that direction.
This is a very flexible way of doing things. Sure, you'll have people complain that this is "slow." But it's only slow in computer standards. By human standards—meaning the person sitting at a desktop or phone UI—it's fast enough that they'll never notice.
On the one side of Sunny's was a gym. On the other side was a Sears catalog showroom. Above the Sears were two apartments. My friends and I lived in one of them. I was a music major, as was another one of us. The other two were graphic design and communications, respectfully.
The Sears was at the end of the street, at the start of which was the police department. It was a one-way street, so the cops were always traveling past. My understanding is that the Sears eventually turned into a topless bar, after the Sears showrooms went out of business.
Where did you work at the school? I worked for a short time in the food service. I waited tables at the Topiary Tree. I also was part of the wait staff for events at the president's house.
This is a mistake is because it puts the broad-scale modularization boundaries of a system in the wrong places and makes the system brittle and inflexible. A better approach is one where large scale system boundaries fall along computational capability lines, as exemplified by modern Entity Component Systems. Class hierarchies that rigidly encode domain categorizations don't make for flexible systems.
Some of the earliest writers on object encapsulation, e.g. Tony Hoare, Doug Ross, understood this, but later language creators and promoters missed some of the subtleties of their writings and left us with a poor version of object-oriented programming as the accepted default.