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