Re: What databases have taught me
From: Jay Dee <ais01479_at_aeneas.net>
Date: Fri, 30 Jun 2006 17:37:34 GMT
Message-ID: <yjdpg.1585$u11.1357_at_tornado.ohiordc.rr.com>
>
>
> Absolutely. f is a part of definition of both.
Date: Fri, 30 Jun 2006 17:37:34 GMT
Message-ID: <yjdpg.1585$u11.1357_at_tornado.ohiordc.rr.com>
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.
>
> 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