Re: The Foundation of OO (XDb)

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 12 Jul 2002 23:15:41 -0400
Message-ID: <tZMX8.1180$lC7.518466664_at_radon.golden.net>

"Topmind" <topmind_at_technologist.com> wrote in message news:4e705869.0206190754.95308be_at_posting.google.com...

> > > > > > I can see that. Video has multiple possible representations. Why

> > force

> > > > > > anyone to choose? Why not support all the possible representations
> > as
> > one

> > > > > > logical type?
> > > > >
> > > > > Because fat types don't belong in databases IMO.
> > > >
> > > > Fat in what sense? In adequately supporting all possible

representations
> > of

> > > > a type? I think that does belong in a dbms.
> > >
> > > What is the "type" you have in mind? Presentation type? (movie,
> > > music, still images, mixed....), Format type?
> > > (Mpeg, MP3....), content classification
> > > (drama, comedy....)?
> >
> > Data type. "Format" and "presentation" are both physical representation.

The
> > full set of operations supported would be up to the implementer of the data

> > type.
>
>
> Both? There are multiple movie "file" formats. (Some are infrequently
> used, but that is besides the point).
>
> For a simple example, it may work. However, I doubt in a large-scale
> library system an adequate type hierarchy could be found. You have at
> least the 3 semi-orthogonal factors I already listed. The more complex
> things get, the less they fit into a tree. The real world changes in
> graph-ways, not tree ways.

Type graphs are not trees. What makes you assume they are?

For instance, a square is both a rectangle and a rhombus, which are both parallelograms.

> > As an aid to understanding the type model in _The Third Manifesto_, consider
> > the value 1. Assuming the type model lacks Natural or Whole, 1 is an Integer
> > value; it is also a Rational and a ComplexRational because Integer is a > > proper subtype of both of these types. Whether one physically represents the

> > value as an unsigned integer of 8, 16, 32 or 64 bits, or as a
> > two's-complement signed integer of 8, 16, 32 or 64 bits, or as a
> > one's-complement signed integer of 8, 16, 32 or 64 bits, or in IEEE

floating
> > point as (0.5)*(2^1) to any given precision or as any other representation,

> > they all represent the same value 1 of the same type Integer.
> >
> > Consider two variables QQ and CC with declared types Rational and
> > ComplexRational respectively. Since Integer is a subtype of both

Rational
> > and ComplexRational, one can assign the value 1 to both of these variables.
> > While the variables have different declared types, they both would contain
> > representations of the same value of the same type, namely representations

> > of the Integer 1.
> >
> > If one compares the two variables in this state, they are equal. If one
> > evaluates the Magnitude operation or the RealPart operation on CC, the
> > result of the operation is likewise the Integer 1. If one evaluates the
> > Phase operation or the ImaginaryPart operation on CC, the result of the
> > operation is the Integer 0.
> >
> > If we evaluate the SquareRoot operation on each of the variables

assigning
> > the result back to the respective variable, the value represented in each

> > variable remains the Integer 1.
> >
> > If we evaluate the Negate operation on each of the variables assigning

the

> > result back to the respective variable, the value represented in each
> > variable becomes the Integer -1.
> >
> > If we evaluate the SquareRoot operation on each of the variables

assigning
> > the result back to the respective variable, the value represented in CC > > becomes the ComplexRational value with RealPart=0 and ImaginaryPart=1 while
> > the other assignment throws an exception. (One cannot assign a value whose

> > most specific type is ComplexRational to a Rational variable.)
> >
> > However, if we evaluate the SquareRoot operation on QQ assigning the

result
> > to CC, the value in QQ remains the Integer -1 and the value in CC becomes

> > the ComplexRational value with RealPart=0 and ImaginaryPart=1.
> >
> > Physically, the type implementer can physically represent Integer values
> > using any of the representations I listed above or even others, and must
> > provide conversions to and from the declared possible representations.
> >
> > Because the Integer type declares possible representations in a variety

of
> > formats, when you bind one to a variable in your program, the programming

> > language can use the representation suitable for the variable.
> >
> > I really think the model has huge potential, and if I were smart, I

would be
> > busy writing a dbms that supports it instead of posting messages on usenet.

> > <g>
>
> Well, personally, I prefer "dynamic" or no typing. Since I started out
> with type-centric languages, this is not a "habitual" preference. I
> just find dynamic typing (or no typing) to be less bureaucratic. I
> realize that one loses some forms of "protection&#8221;, but gain
> simplicity and clarity in the process. Which end of the tradeoff scale
> is more "hurtful" seems to be subjective. Different people are
> bothered by different things in different ways and different amounts.
>
> As for your number examples, I would rather see a more practical
> application of your perceived typing approach. I rarely deal with
> imaginary numbers, or what-not at work.
>
> It also seems to result in a proliferation of conversion combinations.
> If you have 8 types and need conversions between each one, then you
> will need, what is it, 8 factorial?, potential conversion operations.

One needs 14 conversions to convert between any two representations when there are 8 representations.

> Regarding integers, I view an integer as a decimaled number with 0
> decimals. No need to differentiate between "integer" and "decimal"
> IMO.

Except that there are plenty of operations defined for Integers that are not defined for Rationals. Consider for instance:

Add(integer a,integer b) returns integer

While integers are rationals, the above operation is not defined for all rationals.

> But, I would be happy to see a "scriptish" database such that the > column types are simply not declared or not necessary.

If you want to model all of your types as subtypes of a universal supertype, you may declare such columns to have that type.

> It is all text
> (or binary) as far as the DB is concerned.

Au contraire. By informing the DB about type, everything is typed as far as the DB is concerned.

> Whether something is a
> "number" or not would be considered a validation issue for the most
> part. To reduce disk space, it could also be a "compression hint".

Is it also merely a validation issue whether a value is a Video? Received on Sat Jul 13 2002 - 05:15:41 CEST