Re: Searching OO Associations with RDBMS Persistence Models
Date: Tue, 20 Jun 2006 09:30:08 -0400
On 2006-06-19 22:33:38 -0400, "Keith H Duggar" <duggar_at_alum.mit.edu> said:
>> 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
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.
> 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