Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

On 1 Jun 2006 14:41:07 -0700, Mikito Harakiri wrote:

> Dmitry A. Kazakov wrote:

>> On 1 Jun 2006 13:07:49 -0700, Mikito Harakiri wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> Operations on functions (subprograms):
>>>
>>> These are easily defined in the realtional world (where we consider a
>>> function as a relation)
>>>
>>>> 1. Mapping (call to) the tuple of arguments to the tuple of results
>>>>
>>>>    Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN
>>>
>>> Calling a function f(x,y) with two arguments x=1 and y=2 is relational
>>> join of three relations:
>>>
>>> 'z=f(x,y)' /\ `x=1` /\ `y=2`
>>>
>>> projected to attribute z.
>>
>> Where you get z for all possible x and y?

>>From an index that corresponds to a function. Similar to index range
>>scan that brings tuples from an ordinary relation, a function index
>>allows to eavaluate only a portion of an (infinite) relation.

>> Another problem is that this is untyped.

It is not same. A type error in a function argument does not make the statement above illegal.

>> You can do it externally, but it should be a function property.

Yes. Object is an ordered pair (type, value). You could add types as "columns". That would get you some sort of dynamic typing for poor. But it isn't static. Then it is not clear how are you going to bridge static and dynamic typing. You need values of types, literals of, equality of. Then sets of types and classes come, also with literals?

>> The third problem is that
>> you need "=" for all things as well as literals for all things. It is a can
>> of worms. Especially function literals aren't easy. What is a literal of
>> sine?

Yes. It is the essence of the OO-RM dispute, as I see it.

Behavioral view does not require either literals or equality. Both are represented as behavior. So literal is a parameterless function: 1:Ø->N, "abc":Ø->String. Equality is a symmetric binary Boolean-valued function. You can define them as and when you wish. If you want 1 is to return the standard input stream, be it so. It isn't a language question.

[ What I really don't understand, is why DB guys so stick to their sacral data. Relational algebra can handle anything exposing a corresponding minimal behavior: has "=", "<" and a copy constructor. ]

>> This is non-constructive. Are you going to compare all inputs and outputs?
>> Even if they model uncountable sets?

Ooch, how do you know what will be asked? The formalism shall either forbid the very question, or else give a reasonable answer to. If functions are comparable they must be.

Behaviorally it is not a problem at all. Don't provide "=" if you cannot implement it. You will loose some types of containers with that, but that's your choice. The language will make all statements about these containers illegal.

>>>> 4. Copy (for marshaling, closures etc)
>>>>
>>>>    := : f -> f
>>>
>>> Copying is not a logical operation.
>>
>> It is. You should consider the computational state as an additional
>> parameter:

State is an element of a proper set. That makes ":=" "immutable", i.e. a standard function. No magic in.

>> It can be specified through relations, of course.
>> Anything can be.

I don't care, because it is quite obvious that even if you get things described as relations, that would not get you a reasonable implementation of. You can neither effectively translate it to existing machine languages, nor create a relational hardware (here I mean things like quantum computing). The notation itself is very heavy for mortals.

What is needed is a formalism capable to describe not only a Turing machine, but also C/C++ and SQL in a conceivable manner. Relations don't fit well. They have too low abstraction level.

RM fanatics might claim that C/C++ does not deserve any attention, being a crap. I don't like it either, but it is not a serious argument. Software written in C/C++ works [sometimes (:-))], that's reality to face. Why it works, how it does, when it will stop working, how a better language should look like?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de