Re: What databases have taught me

From: Jay Dee <>
Date: Fri, 30 Jun 2006 17:37:34 GMT
Message-ID: <yjdpg.1585$>

Dmitry A. Kazakov wrote:
> On 30 Jun 2006 09:39:29 -0700, Marshall wrote:

>>Dmitry A. Kazakov wrote:
>>>On 30 Jun 2006 08:39:09 -0700, Marshall wrote:
>>>>>Side note: in a strongly typed language "extension" of an operation can be
>>>>>accomplished only through an "extension" of the type (actually a class of).
>>>>>This happens by adding a new type to the class, so that the operation
>>>>>extension be defined on that new type.
>>>>I believe you are descring OO here, yes?
>>>Actually any typed system with user-defined relations on types, I don't
>>>think that it is any specific to OO. Nothing prevents RM from allowing
>>>polymorphic values in tuples. Also tuples themselves could be made
>>>polymorphic as well (to support mixed logics, for example, or to attach
>>>some constraints etc).
>>Mmmm, what I was trying to point out is that it is a somewhat
>>OOish idea to consider functions on a type as part of the
>>definition of that type.
>>Given a set A, and a set B.
>>Given a function  f: A -> B
>>We would not *necessarily* consider f as part of the definition of A.

> Absolutely. f is a part of definition of both.

Well, no. A function, let's say, an operation on integers which returns a rational (approximation, of course), like DIVIDE, requires that the types exist before the function -- but the types don't require the function at all. Granted, many OO languages bundle the methods up in the class -- but that's a mistake.

> type <-> function is a relation. "Member" function is rubbish. BTW, when I
> talk about multiple dispatch I do include results of functions. So, say
> + : A x B -> C
> is triple dispatching. It is an operation of types A, B, C.
Received on Fri Jun 30 2006 - 19:37:34 CEST

Original text of this message