Re: Searching OO Associations with RDBMS Persistence Models

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 20 Jun 2006 09:30:08 -0400
Message-ID: <2006062009300811272-unclebob_at_objectmentorcom>


On 2006-06-19 22:33:38 -0400, "Keith H Duggar" <duggar_at_alum.mit.edu> said:

> Robert Martin wrote:

>> Cimode wrote:
>>> How did you define *identity* on these semantic elements
>>> without a key?  What other mechanism of identification
>>> have you used to coherently identify these semantic
>>> elements? Do you suppose they is a need to distinguish
>>> them or not?
>>> 
>>> Just curious.
>> 
>> An object has an intrinsic identity within the computer.
>> You could think of this identity as the pointer to the
>> object; but this is an approximation at best. Some
>> languages expose the numeric value of that pointer, and
>> some don't.  Others allow an object to have more than one
>> address.  So, although an object is a tuple, the notion of
>> a key as one of the fields of the tuple that uniquely
>> identifies the tuple, is not part of OO.

>
> Aren't /this/ in C++ and /self/ in SmallTalk conceptually
> fields? (Albeit second-class fields.)

I'm not an expert in Smalltalk, so I don't know if the value of 'self' is consistent regardless of the method being called. I think it is; although I don't know if you can use the *value* of 'self' (as opposed to the value of the object it refers to) as a key into a dictionary.

In C++, 'this' is most definitely not like a field. In C++ an object can have more than one pointer value. In the case where D inherits from both A and B, the 'this' pointer value will be different depending on whether you are calling a method implemented in A, B, or C. Thus, the 'this' pointer is not guaranteed to be a unique value. Therefore, even though the 'this' pointer has a true value separate from the value of the object it points to, it cannot be reliably used as a key into a dictionary.

> And the fact that in
> C++ an object can have multiple numerical addresses is just
> an implementation artifact.

One that has significant implications when thinking about keys.

> Suppose this were not the case.
> In other words, suppose a hypothetical language in which
> every object had a unique numerical address. Would that
> still be an approximation of indentity? If so why?

There are object whose *values* are their identity, irrespective of their location in memory. For example, the object: "boolean::true". There may be many instances of this object, each of which has it's own pointer in memory; however it is quite legal (and common) for programers to write code that assumes that all instances of "boolean::true" are the same object.

In the end, there is a difference between RM, in which the concept of identity is inexorably tied to the concept of 'key', and OO in which there is no concept of 'key' and the mechanism of identity is fuzzy.
>
> Do you find any of the arguments in favor of representing
> identity as explicit data reasonable? If so which ones?
> Finally, which argument(s) against explicit representation
> of identity do you find most compelling?

Within a RDB the idea that identity == key is foundational, and I could not argue against it. In OO the idea that we should universally adopt the relational model and always have keys for our objects is just silly; as is the notion that OO is somehow an inferior entity because objects don't necessarily have keys.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |
Received on Tue Jun 20 2006 - 15:30:08 CEST

Original text of this message