Re: Entity and Identity

From: Walter Mitty <wamitty_at_verizon.net>
Date: Sun, 27 Sep 2009 13:59:30 GMT
Message-ID: <6dKvm.3423$Jd7.2925_at_nwrddc02.gnilink.net>


"noyb" <no.spam_at_please.net> wrote in message news:X2zvm.194877$8B7.134823_at_newsfe20.iad...
> Walter Mitty wrote:
>> "noyb" <no.spam_at_please.net> wrote in message
>> news:MNgvm.29468$944.14847_at_newsfe09.iad...
>>> The RM is a self-contained model, and as such, can circumscribe
>>> the identity of a tuple, and it requires specifying a means to
>>> identify every tuple.
>> Let's not conflate the identity of a tuple with the identity of the
>> entity that an item of data in the tuple pertains to.
>
> I'm not. But O-O programmers treat their objects much as we
> do "natural world" objects; vis they don't concern themselves
> with theory, only with pragmatic results.
>
> You failed to comment on the fact that a tuple which has more
> than one instantiation (location) is still *made to behave* as
> though it was the same object (by being confined within ACID rules).
> That supports your original assertion (identity derives from state
> only) against those who claimed that location is also part of state.
>
> You also failed to comment on the pointers I gave to my project,
> which is a substantial and so-far effective attempt at getting us
> out of our Vietnam, by uniting the best of object and relational
> approaches under fact orientation. Please read carefully before
> dropping any more of the pugnacious one-liners that this group is
> known for.

I intended no pugnacity in my response. And even in retrospect, I see no pugnacity in it. If you are seeking pugnacity to validate your perspective, I am sure others will accomodate you. It appears that has already begun.

The fact that I commented only on part of your response and not the entire response was not a failure but a choice. You draw inferences from my omissions at your own peril.

For a variety of reasons, I prefer the word "representation" to "instantiation". And, in the cases you outlined, what we have is not multiple representations of the same tuple, but multiple copies of the same representation. It's inherent in data that data can be copied. A lot of (real world) objects cannot be copied. Managing data in such a way that the multiple copies of the same representation of a tuple are bound together in some fashion that relates to ACID is not a pretense, by any stretch of the imagination.

It may seem that I'm being picky about words, but I'm not. I'm trying to be careful about concepts. Received on Sun Sep 27 2009 - 15:59:30 CEST

Original text of this message