Re: Searching OO Associations with RDBMS Persistence Models
Date: 20 Jun 2006 13:02:26 -0700
Robert Martin wrote:
> Keith H Duggar wrote:
> > 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 ...
> 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.
So whether or not a thing is a "field" depends on 1) whether it can be used as a key in a dictionary 2) that's it's value is consistent regardless of method call 3) that it's value is separate from it's containing object?
To me, none of those (except perhaps 3) seem to be defining notions of "field". Therefore, I'm wondering why you believe they are relevant to the question I asked. Can you provide the (hopefully concise) definition of "field" that you employed above?
> > 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
Yes, though just there I was thinking about "fields" not "keys". Are the notions of "field" and "key" tied? Perhaps this will be clearer to me once you give the definition of "field" used above.
> > 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.
Where did I mention the relational model? What I /did/ ask is which arguments you found compelling both for and against representing identity as explicit data. In other words identity as value regardless of whether identity is tied to value (as in your boolean::false example) or place (where identity would be a unique "address" of some sort).
Now I can somewhat read between your lines to conclude that you think identity as explicit data is "just silly". Please explain why. And note, you /need not say anything about RM/. Confine yourself to the hypothetical language (or language implementation) where every object has a unique ID (like an improved C++ address). Why is this "just silly"?
- Keith -- Fraud 6