Re: Value (was: Mixing OO and DB)

From: Jan Hidders <hidders_at_gmail.com>
Date: Thu, 28 Feb 2008 01:24:07 -0800 (PST)
Message-ID: <2d8e2a19-1dd3-49ed-89d3-5c2d9320d26a_at_e23g2000prf.googlegroups.com>


On 25 feb, 04:49, David BL <davi..._at_iinet.net.au> wrote:
> On Feb 24, 3:56 am, Marshall <marshall.spi..._at_gmail.com> wrote:
>
>
>
> > On Feb 23, 3:55 am, mAsterdam <mAster..._at_vrijdag.org> wrote:
>
> > > > For what it's worth, lately when I think of "value", I just think
> > > > "a member of a set."
>
> > > Is it right to say: you are trying to avoid 'value' as primitive term?
> > > If so may I ask why?
>
> > Lately I am viewing things through the lens of set theory.
> > Set theory already has its primitive terms: "set" and the
> > membership relation. These are sufficient for its needs.
> > Value can be defined in those terms, so no need to add
> > an additional primitive term. (And we want to minimize
> > the primitives.)
>
> I've been thinking that when we say that a (value) type is a set plus
> operators on the elements of the set, we should qualify that and say
> by definition a type must be unique up to isomorphism, and as far as a
> computer scientist is concerned it is only necessary to think of the
> elements as being distinguished in the context of the given type.

That would then be an abstract data type. I would agree that it is reasonable to say that every type is in fact an abstract data type. But what is essential for value types in the context of database theory is that the elements of the sets have representations associated with them, i.e., ways in which they can be represented in a computer or to a human being. That IMNSHO is the defining characteristic of a value data type vs. other data types, and thereby also defines what is and is not a value.

Are you paying attention mAsterdam? ;-)

Received on Thu Feb 28 2008 - 10:24:07 CET

Original text of this message