[bsaul]

My personnal favorite regarding this kind of philosophical thinking similarities is Husserl "eidetic variations" method for finding what properties constitutes the essence of a concept (*).

We programmer do it instinctively, but having read about it gives me such a greater confidence to actually apply it methodically every time i design a type hierarchy...

(*) basically, the idea is to mutate the property, and see if the object's essence is unchanged. If it is unchanged, then the property isn't constitutive of its essence. As an example, changing the color of a table doesn't change the fact that it's a table, so "color" isn't an attribute of the "Table" concept. Number of feet, however, could very well be (or at least a boolean "has feet" ;)

[xtagon]

In ontology, you can think of the concept of "table" as being a role that an object can fulfill (possibly for a given period of time) rather than strictly a specific class of object. For example, let's say you move into a new home and haven't set up all the furniture yet, so you temporarily use a crate as a table. Even the phrase "as a table" suggests that it's more of a role than a class. If a crate can be a table, and a crate has no feet, what makes a table with feet more of a table than that? It serves the same utility and can naturally be described as such in conversation.

By that line of thinking, the essence of a table may have very little to do with it's shape, and more to do with it's purpose. But I can see how that just opens up a new rabbit hole to go down...