4 ms·
Data modelling in OOP is an exercise in coming up with Platonic ideals, resulting in a hierarchical (tree-like) ontology as you try to choose of the atributes a
by hcarvalhoalves 5y ago
Data modelling in OOP is an exercise in coming up with Platonic ideals, resulting in a hierarchical (tree-like) ontology as you try to choose of the atributes as the categorisation dimension, and leaving everything else as properties.
class Animal
class Mammal inherits Animal
class Feline inherits Mammal
class Cat inherits Feline
...
This is different than just asserting facts with data, which can lie in multiple dimensions.
Is Feline
Is Mammal
Is Fluffy
Is White
Does Meow
The later is a much more flexible data model as it more closely mimics observed (subjective) reality, and is less disturbed when a new (counter-)example is introduced, but is also harder to reason about than idealised categories.
- wwweston 5y agoHence traits?
- beaconstudios 5y agoAnd ECS is fundamentally a trait system!
- dkersten 5y agoI know all the terms are overloaded nowadays so everything’s kinda unclear but I always wished that ECS components had been called traits, because adding a component to an entity gives it some a trait like “this thing has a position in the world” or “this thing can be drawn” (and perhaps have systems named “behaviors”, because systems add behavior to entities based on the traits/components that they have) Years ago, when ECS was just starting to be talked about (after Adam Matrins blog posts), I wrote a toy ECS where I used that naming convention. Nowadays I stick to the mainstream terminology since that’s what other people know.
- beaconstudios 5y agoYeah I've commented before that "entity component system" is roughly synonymous with "thing piece thing" or something like that - it's a really bad name because it's so ambiguous. Anything including the term trait would be 1000x better because at least "trait" means something.
- bcrosby95 5y agoI think it's named ECS because before then entity+component designs were common in games. ECS generally took the behavior off the C and puts it in the S.
- pjmlp 5y agoThey have, but there is a certain tendency to ignore CS literature. "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Beyond-Object-Oriented-Programming/dp/0201178885 https://www.amazon.com/Component-Software-Beyond-Object-Orie... 1st edition, 1998
- throwaway894345 5y agoTo your point, there are programs that deal in ontologies. These are the only times that it makes sense to care about the relationship between things. For example, an ontology might have a concept of a city and it might know that Munich is a city. But this is all data, it isn't about "types". It never makes sense to write `class Munich extends City {}` for the purpose of your program. Rather, you might have: struct Entity { name: string, parent: Option<Entity>, } let city = Entity { name: "city", parent: None }; let munich = Entity { name: "Munich", parent: Some(city) }; That said, if you really wanted to make life hard for yourself, you could use types as data provided your language has a runtime type system and reflection (you could dynamically generate `class City` and `class Munich extends City` when deserializing `[{name: "city", parent: null}, {name: "Munich", parent: "city"}]` or something). But this is the kind of Rube-Goldberg territory that "Kingdom of Nouns" thinking leads us toward.
- inopinatus 5y agoUh, no. Either of those are possible without leaving the OO paradigm, and only very poorly taught and inexperienced students model data as an object inheritance hierarchy.
- coldtea 5y agoIf only. Spoken like someone who has never seen any kind of representative sample subset of real world code...
- inopinatus 5y agoNo, the problem is that code by poorly taught and inexperienced developers is rife. Heck it’s on display throughout the threads on this topic; for maximum irony, often as an example of “why <concept> is bad”, the author not realising this merely telegraphs their own limitations.
- AdieuToLogic 5y ago> Data modelling in OOP is an exercise in coming up with Platonic ideals, resulting in a hierarchical (tree-like) ontology as you try to choose of the atributes as the categorisation dimension, and leaving everything else as properties. Only if that is how you choose to model the problem domain. > This is different than just asserting facts with data, which can lie in multiple dimensions. The "Is ..." examples you detail can just as easily be modeled "in OOP" as: class Animal { private knownFacts = ... def is (fact) ... } Without the need for "a hierarchical (tree-like) ontology", since obviously this would be a poor choice in this situation.
- hcarvalhoalves 5y agoNot the same thing, as the facts are now a property of Animal. My second example doesn't even mention Animal. You still have the problem of "putting things into a category" vs. just asserting facts.
- meheleventyone 5y agoThere is an implicit subject you are asserting facts about though. You clearly are talking about a fluffy, white Cat in your example. It’s essentially structural rather than nominal typing. The “fluffy, white Cat” is defined by its traits. We could define a type Cat which has a subset of those traits and then be able to use our “fluffy, white Cat” anywhere we can use a Cat. We only name them to avoid having to name all the traits all the time. Doesn’t make it any less object based. Structural typing is really cool though. An object built from a named, saved recipe will work just as well as something cobbled together on the fly and at runtime you won’t even know which is which. It’s the basis of a lot of general purpose game engines composition based game object interface. I’ve also found it extremely fun to use with TypeScript.
- hcarvalhoalves 5y ago> There is an implicit subject you are asserting facts about though. You clearly are talking about a fluffy, white Cat in your example. No, I'm not, because I didn't assert this fact (it's a Cat). See how hard it is to break free from this mindset of objects.
- neolog 5y agoIf f(x) is implemented for white xs and separately for fluffy xs, how do you disambiguate f(x) for x that's both white and fluffy?