Bundle Substance Mismatch

According to the wikipedia, objecthood is: "is the state of being an object." I particularly liked that article, specially the part that says that:

"Theories of objecthood address two problems: the change problem and the problem of substance." (http://en.wikipedia.org/wiki/Objecthood)

The answer to the change problem is the answer to the following question:

if object manifest themselves as cluster of properties... if you remove all the properties... what remains? According to substance theory, the answer is a substance (that which stands under the change)... if we apply this to Object Relational mapping... then.. the objectId (primary key) is the substance? Could this be used as a philosophical justification for the immutability of the primary key?

Then the text in the wikipedia continues: Because substances are only experienced through their properties, a substance itself is never directly experienced. Is that a justification for never using the id (keeping it private)? Of course, there is another theory, the theory that since substance cannot be experimented... then it doesn't exist, that is the "bundle theory".

In bundle theory all objects are merely a cluster of their properties and therefore... everything changes always... and no such thing as object ids/ primary keys exist in the real world. This has an impact in relationships too, because we usually define a relationship (in object/substance theory?) as something that binds together 2 or more objects (at their substance level?)... but since object's substance doesn't actually exist then there isn't such thing as a "relationship" between two objects..

According to this, relationships can only exist as something defined at the "property cluster level".. two (or more) objects aren't really related at the substance level... they simply "share a property" (is that why in SQL there isn't a way to make queries taking advantage of the integrity relationships? is "shared property" a better name for integrity relationships?)

And the thing gets worse: Whether objects are just collections of properties or separate from those properties appears to be a strict dichotomy. That is, it seems that objects must be either collections of properties or something else. Is that the philosophical foundation for the object/relational impedance mismatch?

So it seems that the conflict between a relational (bundle theory) and object (substance) worldview has been there since way before a relational database or an object oriented language was invented...

I wonder what else could I learn from reading about this philosophical theories... (could there be a third one? is there a software programming paradigm for it? maybe we should learn PhilosophyAsFoundationForSoftwareEngineeering?) maybe the next software development paradigm is hidden in philosophy?

I think there could be a third one. Actually, I think there is a continuum. What I think about this dichotomy is as follows:

The more certain you are about your domain and the easier it is to differentiate your objects, the more you tend toward relational (and exact mathematical) models. To use the objecthood terminology, this is because you are certain of your substance - because it is easy to separate objects.

As it gets more difficult to define your objects (because of vaguesness in customer specification, missing experts) or if these tend to change over time (changing requirements), the more you tend toward the object oriented paradigm and here you go from static typing to dynamic typing (this is already a further dichotomy). As you get uncertain about your substance and tend to bundles (after all objects are property bundles without a primary key), your identity of objects becomes a topic in iteself (overriding equals...).

But I think the path doesn't end here. As the speed of requirements changes picks up and as we get more flexible in satisfying customers, I think a new paradigm will earlier or later turn up which allows to work with vague terms from the beginning. This is where there are not even stable bundles, but where the interpretation of a bundle (the actual set of properties) depends on context.

-- GunnarZarncke (see also VaguesDependingOnVagues?)

(moved from TopMind, because it is TooBigToEdit)

Hi top! I would like to know your opinion on the relationship between the philosophical BundleSubstanceMismatch and the ObjectRelationalMismatch?.. I like object oriented programming... I also like the relational power of databases, and contrary to many others I believe saying object orientation is wrong can open the minds of people to find ways to enhance object oriented programming... enhance relational programming... or making people look for a new paradigm that may solve (or make obsolete) the problems of the object relational mismatch... My main question would be... can we extract knowledge form philosphy that could be used to create a new, better paradigm? -- LuxSpes

I usually don't like to get into discussions about the "real" nature of reality unless I find a direct relationship with software issues. Both relational and OO are rough approximations of reality, and sometimes ignore reality in order to make managing the model easier for the model maintainers. For example, Goto's perhaps may better reflect reality, but we avoid them because they make code harder to reason about. Whether those reality-analyzing philosophies can result in a better paradigm, I don't know. Anyone's welcome to try. -- top

(So basically you are a follower of LogicalPositivism?)

Alright, but... don't you find it intriguing that the BundleSubstanceMismatch is so similar to the ObjectRelationalMismatch?? After all, don't you say that OOP is probably a personal preference rather than a universally, objectively superior paradigm? (If the nature of reality is actually object oriented, that could be an argument in favor of the intrinsical superiority of object orientation... specially when used to describe models that describe thigs that happen in the real world (and a lot of biz applications are about automating real world processes).)

Also, if math can be used to say that the relational model is better fit to solve software problems (having math behind the relational theory is one of its strong points agains object orientation... isn't it?... Why philosophy can not be used with the same purpose? After all you also say you belive that SoftwareEngineering is far more about psychology than "purest" disciplines like math... doesn't that make philosophy a better ally for your relational (bundle) point of view? (or is that you believe that philosophy is purer than math?) I believe philosphers have been trying to solve this problem of "what is the best theory to explain what is the nature of the knowable things?" for more time that software engineers. A knowable thing might me an object (a substance) (if object orientation is the right path) of might be a tuple (if relationa/bundle teory is the right path).

Philosophy has not solved these problems in any concrete and objective way either. This is yet another reason why I believe EverythingIsRelative. We have two choices to answer why an objective solution does not exist: 1) we haven't found it yet, 2) there is no objective solution because the merits are relative to the observer.

Just read this: Some philosophers, notably of the Platonic school, contend that all nouns refer to entities. Other philosophers contend that some nouns do not name entities but provide a kind of shorthand way of referring to a collection (of either objects or events). In this latter view, mind, instead of referring to an entity, refers to a collection of mental events experienced by a person; society refers to a collection of persons with some shared interactions, and geometry refers to a collection of a specific kind of intellectual activity. Doesnt that strike you as a very close to that discussion of what should be an object... what should be a collection... if we should have tools to describe actions on things using collection verbs, or we should be thinking in terms of individual entities? (should we think on tables or on indivual objects? should operations be messages on objects or tasks that act upon collections? Shouldn't Ontology be something we as Software Engineers should study to have better tools to try to understand complex systems (such as the reality?)... I mean, if one (or many) of this philosophical systems (philosophical tools?) seem to work fine to better understand part of the reality (the greatest system of all)... couldn't it help to model systems in a better way?

My observation is that OO fails to factor commonly-needed CollectionOrientedVerbs into a reusable standard. OO is too individualistic. And, actions are often not permanently one-to-one with domain nouns. OO does not match reality well, at least as I perceive it, and does not factor out commonalities well (collection handling). I am not sure repetition factoring is related to matching reality, by the way. It is an abstraction of commonalities found in reality (or at least our models of reality) so that we can reference existing commonly occurring idioms rather than copy-and-paste. The real world duplicates up the wazoo (often without consistency), but we often don't want to keep this trait in our software, at least not to the extent it exists externally.

Somewhere around this wiki there are other examples where we intentionally deviate from reality in order to make software simpler, more manageable, and/or better. Multi-indexing (in computer) instead of directly modeling (paper) card catalogs in the book library is one I remember. I am happy to toss reality in my domain models when it is unnecessarily messy. Similarly, when mass production and interchangeable parts began showing signs of being more efficient than hand-crafted parts, some of the old ways of doing something had to change. It was no longer practical to replace a broken part by custom-building one because it was cheaper just to order the replacment or take it from stock. But the distribution infrastructure also had to become more efficient to get the right parts from the right factory or storage yard. The "reality" of craftmen and distribution systems had to change for the sake of efficiency. The reality changed to fit the system, not the other way around. If set theory makes the graph-hoppers unconfortable, so be it. If users have to learn how to use a set editor instead of trees to classify their products correctly, so be it. It is a bigger learning curve and/or more specialists, but this is usually the case with progress.

Once upon a time a man was travelling alone. He came to a vacant house toward the evening and decided to spend the night there. About midnight a demon brought in a corpse and left it on the floor. Shortly, another demon appeared and claimed the corpse as his and they quarrelled over it. Then the first demon said it was useless to argue about it further and proposed that they refer it to a judge to decide the possessor. The other demon agreed to this and, seeing the man cowering in the corner, asked him to decide the ownership. The man was terribly frightened, for he well knew that whatever decision he might make would anger the demon that lost and that the losing demon would seek revenge and kill him, but he decided to tell truthfully just what he had witnessed. As he expected, this angered the second demon who grabbled one of the man's arms and tore it off, but the first demon replaced the arm with one taken from the corpse. The angry demon tore away the man's other arm, but the first demon immediately replaced that with the other arm of the corpse. And so it went on until both arms, both legs, the head and the body had been successively torn away and replaced with the corresponding parts of the corpse. Then the two demons, seeing the parts of the man scattered about on the floor, picked them up and devoured them and went away chuckling. The poor man who had taken refuge in the deserted house was very much upset by his misfortunes. The parts of his body which the demons had eaten were the parts his parents had given him, and the parts that he now had belonged to the corpse. Who was he, anyway? Realizing all the facts, he was unable to figure it out and, becoming crazy, he wandered out of the house. Coming to a temple, he went in and told his troubles to the monks. People could see the true meaning of selflessness in his story.

I believe this buddhist story is a nice example how hard it is to deal with the bundle substance mismatch... We might not even be able to know our own substance... Do we even have one? Or are we just a bundle? Is memory our substance? What happens then when we forget something? Maybe there is no substance an we are just an ever evolving bundle?

In FunctionalProgramming, one strives to make everything not only a bundle, but a bundle whose properties are fixed. Only the very tip-top layers of the program--those which interface with the "real world"--have any substance; everywhere else, when one would normally change the property of a substance, one instead creates a new bundle which is a copy of the old one, except for that property. There is no notion of 'object identity' because objects don't have any. The nice thing about this is that it maps better to things inside the computer, such as code which does physics calculations [much better written as equations], or relational databases [are you listening, TopMind?]--because on the computer, nothing actually changes unless the processor tells it to.

CategoryPhilosophy