Re: The Foundation of OO (XDb)

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

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

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

> > > 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.

Yes, you can *force* 3 orthogonal factors into a tree, but that is an ugly construct to work with IMO.

"Types" are too dependent on hierarchies. Even most type-liking OO fans tend to gravitate toward GOF patterns instead of trying to make complex multiple independent types (M.I.) work. "Types" are an intellectually-satisfying concept, but tend to get tangled up in reality.

A "type" of media can have the same problems as defining "types" of people, but at a smaller scale. As the system grows more complicated and mature, similar problems will pop up. So yes, you *could* say that "well, media is simpler than people, so types can work". That may be true for the short-term, but it is not a scalable excuse.

> 
> 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”, 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.

Regarding integers, I view an integer as a decimaled number with 0 decimals. No need to differentiate between "integer" and "decimal" IMO. But, I would be happy to see a "scriptish" database such that the column types are simply not declared or not necessary. It is all text (or binary) 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".

I wouldn't miss "types", both at the base level, and "fat type" (ADT's, etc.) stuff. The type rules just get in the way and differ too much between different systems, requiring more conversion work and clutter. They are anti-KISS IMO.

If you want to "sell" a new typing system, you are talking to a hard sell here. If I am by chance forced to use OO, I would gravitate toward the likes of Smalltalk and Python instead of type-centric Java, OO-Pascal, and Eiffel.

-T- Received on Wed Jun 19 2002 - 17:54:38 CEST