Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Sun, 17 Feb 2008 19:12:50 -0800 (PST)
Message-ID: <66921cc0-be79-4c50-aeff-f40e37cfe72b_at_e23g2000prf.googlegroups.com>


On Feb 16, 8:38 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Fri, 15 Feb 2008 17:45:16 -0800 (PST), David BL wrote:
> > On Feb 16, 5:24 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:
> >> On Fri, 15 Feb 2008 08:46:54 -0800 (PST), David BL wrote:

> >>>Therefore, as Invert() has
> >>> been written (1) is the only option.
>
> >> As a counterexample, consider C (complex) instead of Z.
>
> > Please provide more details. Are you alluding to covariant return
> > types? ie
>
> > Complex Invert(Complex x);
> > Real Invert(Real x);
>
> Yes. Covariant result for Real :> Complex inheritance is appropriate and
> reasonable. But it is not for Real :> Integer. This is a mathematical fact,
> rather than a property of some arbitrary types system. The problem is that
> C is a field, Z is not. Thus the types system shall be able to capture what
> behavior (mathematical structure in this case) you are going to inherit
> upon derivation from R, a ring (for Z) or a field (for C). There is no way
> to know it in advance, and if we restricted it to "all what R is", we would
> get just another R.

I assume the notation T :> S means S is a subtype of T. I think you are suggesting (a definition of subtyping) that T :> S implies that for any algorithm, all occurrences of T can be replaced by S. However, then there would be no valid subtyping relationships between Z,R and C. For example, R :> C isn't valid because R is an ordered field whereas C is not. C :> R isn't valid because C is an algebraically closed field, whereas R is not. Z isn't a subtype of either R of C because Z isn't a field. Neither R or C is a subtype of Z because only Z has the property that its positive elements are well-ordered.

I would suggest what you're after is some concept of abstract valuetypes  like "Ring" and "Field". I can see it could be useful to write data structures and algorithms in their most generic sense without explicit parameterisation. For example matrices are defined on an abstract field. This still allows for many nontrivial functions to be written - eg matrix inverse. I can imagine indicating that R,C are subtypes of Field according to this parameterisation notion of subtype.

However independently of such as feature, I still believe it is important to capture the quite different concept of subtyping espoused by C.Date, because it concerns implicit conversions of value-types (as distinct from parameterisation), and that's very important. Treating Z as a subset of R, or R as a subset of C is very useful. A function that accepts a complex number can be passed a real number without explicit conversion. A function that returns a real number can used to initialise a complex variable. Implicit conversions are deemed valid if and only if *exactly the same logical value* is represented before and after the "conversion". This implies two things: the conversion cannot silently drop information, nor can it silently add information.

It follows that it is wrong to say that a ColouredRectangle is a subtype of a Rectangle, because a ColouredRectangle value is logically different to a Rectangle value. I think it's clear that slicing is suspect. Imagine a little movie of slicing and play it in reverse - isn't it equally suspect? I now think out-substitutability is just as suspicious as in-substitutability in this case. When one assigns a ColouredRectangle variable from a Rectangle value, how do you know what to initialise the colour to? Does the compiler guess what colour to use? Having the compiler silently drop or add information seems very bad, and surely must interfere with one's ability to reason about one's program.

Returning back to abstract value-types like "Field", it is important not to confuse them with "abstract" supertypes in the sense of C.Date, because the latter are *union types*, and represent the union of all possible values from its sub-types.

By contrast, a "Field" is actually a type of a type and I think the distinction is important. The idea here is that a type like Complex is regarded as itself a value, which means you can have types defined over types. It would be interesting to some up with a suitable syntax and see whether the average programmer is able to comprehend it. My feeling is that explicit parameterisation is better but I could easily be wrong.

[snip]

Please say if I didn't address any of your subsequent points that I snipped. Received on Mon Feb 18 2008 - 04:12:50 CET

Original text of this message