Re: Microsoft and the two great blunders

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Fri, 26 Dec 2003 00:04:03 -0800
Message-ID: <bsgq38$cmb87$1@ID-152540.news.uni-berlin.de>

Alfredo Novoa wrote:
> Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bsdbmu$c7iot$1_at_ID-152540.news.uni-berlin.de>...
>
>

>>Table. Everybody and their grandmo know what a table is. Fore you, it is 
>>a relvar.But grandmo doesn't know what a relvar is.

>
>
> My grandmother knows what a relation is, and it would be easy to
> explain her what a variable is. And of course she knows that a table
> is a board supported by several legs on which food is served :)
>

Then your mother may not speak English very well,

> Relation is a common term out of the crazy IT world. Biz guys don't
> say: give me a table of customers.
>

They don't say give me a relation of customers either.

> But my main complaint is about using a single word for table value and
> table variable. They are fundamentally different concepts.
>

Who's using that ?

> Table is more appropiate for the SQL bags, and relation is more
> appropiate if you are talking about a relational database.
>

Ahem, you mean relvar ?

>>A 
>>relation is a set of tuples. Therefore a table may store all the
>>values of a certain tuple type.

>
> A relation is more than a set of tuples.
>
> I have never seen a table containing all the values of a tuple type at
> practice. In many cases it would be physically impossible.
>

All the values in the domain of interest that are of a certain type. For example all the value of Employee type.
>

>>So then the great blunder, it's not such a big deal, or is it ?

>
> It does not have relationship with the great blunder.
>

Oh, but that is allegedly one of the great blunder. Read TTM appendix.

>>>>Quite nice. But according to D&D types are sets of values. Well, then a 
>>>>relation is a set of value.
>>>
>>>According to D&D and many other people, types can be viewed as sets of
>>>values associated to sets of operators. 
>>
>>Not unless they've written one more edition of The Third Manifesto where
>>they corrected their mistakes.
>>
>>Here's a reference for you:
>>http://www.hughdarwen.freeola.com/TheThirdManifesto.web/D.GRM
>>
>>As you may see, the user who declares a type has no mean to properly
>>express a set of operators as integral part of the type definition.

>
>
> Any operator may be a part of several types, and you can express that
> without problems with that template (and flawed) grammar.
>

So if an operator is part of several types, you've got a problem. Are operators part of the type definiton or not ?

> (BTW is anybody interested on the mistakes of that grammar?)
>
> Here is an appropiate quote:
>
> -
> A type is a defined finite set of values and associated
> operators. The associated operators consist of those defined to
> operate on values or variables of that type and those that,
> when invoked, return values of that type.
> -
>
> http://www.hughdarwen.freeola.com/TheThirdManifesto.web/taamoti.paper.pdf
>

That quote doesn;t solve anything, at best it is a declaration of intention, plus it does not clarify if operators are part of type definition or not.

>>Your definition "sets of values associated to sets of operators" is
>>equally unsatisfactory. Does it mean that the definition of operators is
>>integral part of type definition ?

>
>
> Yes.
>
>

>>Or to make it easier for you to express, here's an example from TTM:
>>
>>TYPE PLANE_FIGURE ... ;
>>
>>TYPE ELLIPSE
>>	IS PLANE_FIGURE
>>	   POSSREP { A LENGTH, B LENGTH, CTR POINT };

>
>
> It is not a complete type definition.
>

So what would be the complete type definition ?
>

>>Now, I wonder what you or  anyone would replace those dots with, within 
>>the framework established by D&D, so that it makes any sense whatsoever.

>
>
> Something like:
>
> type Plane_Figure union;
>
> I don't remember the syntax, my copy is 600 km far. It should be the
> equivalent of an "abstract" type.
>

Oh. But

type Plane_Figure union;

Is void of content. A proper abstract data type is something entirely different, and we already have proper mathematical formalisms to define that. Any of those formalisms haven't found their way into tutorial D or any related places.

What *is* Plane_Figure , and what's the purpose of that declaration ?

>>But if the framework is so weak that it can't even deal with this much 
>>it should be either reformed or discarded altogether.

>
>
> IMHO what is a bit weak is your knowledge of the model.
>

IMHO your knowledge of the entire subject of type theory is weak.
>

>>>On the other hand, a relation
>>>is an individual constant. But the "great blunder" is to confuse types
>>>with relation variables, not whith relations (values).
>>
>>Nobody is confusing anything.

>
>
> Then we live in different worlds.
>
> Have you readed this:
>
> http://www.ambysoft.com/persistenceLayer.pdf
>
> It is the inspiration of dozens of SourceForge and comercial projects.
>

So what ? People are free to waste their time however they wish.

>>And this is no blunder. Most people *map* entity-types to tables. I.E.

>
>
> Entity-types are virtually meaningless. Is the E/R "model" your idea
> of a formal framework? }:)
>

Yes, it is. A little bit of reading on the subject wouldn't hurt you.

Try Thalheim "Entity Relationship Modelling - Fundations of Database Technology" Springer Verlag 2000

> Most people "map" entity types to classes and classes to table
> variables.
>
>

>>for every entity type found during analysis, they typically create a
>>table in the relational schema to store values of that type.

>
>
> That was before the persistence framework fad. Now they typically
> create a Java or C# class and they "map" the class to a table or
> several tables using a "persistence layer".
>
> It is clear on the slides.
>

So you still haven't shown any problem.

Cheers,
Costin Received on Fri Dec 26 2003 - 02:04:03 CST