3 ms·
Unless your program's goal is to ontologically categorize objects, #1 is a trap that will just bite you in the ass. In the physical world, if I have a rectangl
by sbov 9y ago
Unless your program's goal is to ontologically categorize objects, #1 is a trap that will just bite you in the ass.
In the physical world, if I have a rectangle shaped box I want to cover, I don't want a square, no matter how much "squares are rectangles". It's no different in a program. What really matters is the behavior and goals of your program. It's cute to say squares are rectangles but if your program needs to let your user independently set width and height then a square is completely useless.
- weberc2 9y ago> Unless your program's goal is to ontologically categorize objects, #1 is a trap that will just bite you in the ass. Strangely, ontological inheritance isn't even useful for that purpose. If you're organizing things ontologically, you certainly want to have runtime access to the relationships in your ontology, which means you should model things as data, not static class relationships (although reflection can turn static class relationships into data, it's a pretty hokey, indirect solution).
- seanmcdirmid 9y agoMost languages that have classes expose inheritance relationships in someway without reflection. Even JavaScript provides a non-reflective instanceof now. You can also reify inheritance relationships more directly by hand of needed.