Re: Microsoft and the two great blunders

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Sun, 28 Dec 2003 22:59:52 -0800
Message-ID: <bsojer$f2ugk$1@ID-152540.news.uni-berlin.de>

Bob Badour wrote:
> "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
> news:e4330f45.0312281200.406f3000_at_posting.google.com...
>

>>Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message

>
> news:<bsgq38$cmb87$1_at_ID-152540.news.uni-berlin.de>...
>

>>>>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 ?
>>
>>You are mixing apples with oranges. The proper question should be: Are
>>operators definitions part of type definition? And IMO the answer is
>>yes.
>>
>>But one operator may be shared by several types.

>
>
> You both are confusing issues. Conceptually, a type is defined by the vast
> set of possible operations for the type. Any given logical design will
> declare only a small subset of that vast set of operations. Whether one
> physically and logically declares the operations proximately with the values
> is largely arbitrary. I suggest that separating the declarations has
> advantages for schema evolution. Regardless whether an operation is declared
> to the dbms at any given point of time, the operation is always a valid
> operation on values of the type.
>
>

I suggest you do some reading on type theory. If you google up a little bit I already put more than enough references (no, you won't find them cited by Date).

After that you might want to test if you have a clear idea on:

• what is a *type*
• what is a *type system*
• what is a *function* (or "operator" if you will)
• what is the relationship between a type and functions operating with elements of that type

And all those answers should be given in the context of building up information systems, thus the following characterstics are a necessity, and not a mere implementation detail:

• modularity
• compositionality
• locality of reasoning
• safety
• simplicity
• elegance

For example what you propose breaks modularity because you can't just expect that a type which is a modular element can be "defined" (sic!) by an infinite number of elements (operations), while separating declarations will break locality of reasoning, simplicity and elegance. Received on Mon Dec 29 2003 - 00:59:52 CST