Re: Microsoft and the two great blunders
Date: Sun, 28 Dec 2003 22:59:52 -0800
Message-ID: <bsojer$f2ugk$1_at_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 - 07:59:52 CET