Re: What databases have taught me
From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Fri, 30 Jun 2006 19:08:30 +0200
Message-ID: <1mxnfautmh7v1.1d3i3v6nossc5.dlg_at_40tude.net>
>
> 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.
Date: Fri, 30 Jun 2006 19:08:30 +0200
Message-ID: <1mxnfautmh7v1.1d3i3v6nossc5.dlg_at_40tude.net>
On 30 Jun 2006 09:39:29 -0700, Marshall 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.
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.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Fri Jun 30 2006 - 19:08:30 CEST