Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Fri, 15 Feb 2008 18:52:10 -0800 (PST)
Message-ID: <e42584c8-7512-46e4-9a18-f271024c2e28_at_e6g2000prf.googlegroups.com>


On Feb 15, 8:13 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Fri, 15 Feb 2008 01:12:22 -0800 (PST), David BL wrote:
> > On Feb 15, 1:27 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> >> I think when I say "substitutability of values" I mean what you call
> >> in-substitutability, and when I say "substitutability of variables" I
> >> mean what you call out-substitutability.
>
> > I take back my claim that "substitutability of variables" means out-
> > substitutability. I think it should encompass both in-
> > substitutability and out-substitutability.
>
> > Therefore I was wrong to suggest that a pointer to a ColouredRectangle
> > variable could be implicit cast to a pointer to a Rectangle variable,
> > because it can lead to subsequent slicing.
>
> An important node. Pointer is a data type distinct from the data type of
> what it is supposed to point to. What you probably meant is that there
> exists a mapping: f : ColouredRectangle -> Rectangle.

Yes that mapping exists. It is surjective but not injective. Not injective means it isn't information preserving (because distinct coloured rectangles map to the same rectangle when the colour is sliced away). IMO for implicit conversions to be applicable, such a mapping must be injective (but not necessarily surjective).

> Which in dreadful C++
> notation looks like
>
> *(Rectangle *)&
>
> (a composition: &, casting and *). In a decent language, which C++ is not,
> the operation * should not be allowed for all types indiscriminately. That
> makes optimization quite difficult. What if Rectangle "physically exists"
> on a different machine in a DB? How can I get its pointer? What is this
> pointer? etc. Getting rid of data, also eliminates hard-wired data things
> like pointers. Instead you get behavior of some objects referencing others.

I don't think I follow. Are you saying

    *(Rectangle *)&

amounts to slicing and you can blame the pointer indirection - ie operator*() ?

> > In the end it's better
> > just to say that subtyping ColouredRectangle from Rectangle doesn't
> > make sense and leave it at that.
>
> But there exists a mapping between them, which makes possible for
> ColouredRectangle to be an extension of Rectangle. In practical terms it
> means that ColouredRectangle can be out-substitutable for Rectangle:
>
> Give_Me_One : <something> -> Rectangle
>
> (this case you considered for circle/ellipse later)

That doesn't change my opinion that sub-typing is inappropriate in this case.

> > If we go back to the much more sensible example of value-type
> > inheritance of circle from ellipse we see that a circle is in-
> > substitutable for an ellipse, whereas an ellipse is out-substitutable
> > for a circle. That suggests to me that a language must distinguish
> > out parameters from in-out parameters, and therefore passing out-
> > parameters using pointers to variables isn't the right approach.
>
> Sure. Note that out and by-reference are different issues. You can have
> copy-out passing for by-value types, and copy-in-copy-out for in-out ones.
> It is an implementation issue.
>
> As for pointers, it is yet another story. T* can be considered as a
> subtype/supertype of T with all issues of substitutability. For instance,
> null is not substitutable in any of the operations of T.
>
> > In the following example an ellipse is out-substitutable for a circle:
>
> > // declaration
> > Circle foo();
>
> > // call
> > Ellipse e = foo();
>
> > I'm not sure I like this terminology of in-substitutable and out-
> > substitutable. It seems easier to me to just remember that a circle
> > value is an ellipse value and note that in-parameters narrow whereas
> > out-parameters widen.
>
> Ah, this is a crucial point. Circle value is not an ellipse value. These
> have different types. It is only so that there exists a mapping which gives
> you an ellipse value from any circle value.

It depends on what "is" means. Using the example of the integers and reals: As mathematical systems it is reasonable to say the integers is not a sub-type of the reals. However it is true that the set of integers is a *subset* of the set of reals.

Perhaps the C.Date approach needs a different terminology (ie than subtype) to avoid this confusion. When Date says integers is a subtype  of reals, he means for example that nonzero integers have inherited real-valued multiplicative inverses. In mathematical definitions of integers that's inappropriate, but for software development I need to see a good reason to disallow it. Can you provide one?

I don't think you need the mapping to give an ellipse value from a circle value. I would rather say the set of circle values is a subset of the set of ellipse values. This seems appropriate even if you have mathematical properties that are available on the system of ellipses but not the system of circles.

> > One of the reasons people tend to pass out parameters as pointer
> > arguments is to support multiple out parameters. I rather like the
> > idea of a language that supports a tuple syntax for multiple out
> > parameters. Eg
>
> > // definition
> > (Circle c, int x) foo()
> > {
> > // Can assign named out-parameters c,x
> > // No need for a 'return' statement!
> > c = Circle( Point(0,0), 10 );
> > x = 1;
> > }
>
> > // call
> > (Ellipse e, int x) = foo();
>
> Right. Anonymous ad-hoc types would make life a lot easier. But again, a
> tuple is a new type with all potential problems of substitutability. Same
> as with pointers, you might wish to consider (T) substitutable for T and
> reverse, for obvious reasons. Or maybe even (T, ...) for T, which would be
> in-substitutable of course. The problem is fundamental, and it does not
> have a universal solution, alas.
>
> What the language should deliver is a clean types model.
>
> As for subtyping, to me, it is just a relation between types. I don't
> expect it to deliver substitutability. It cannot. What it can and should,
> is to help me to deal with the problem.

Can it? I'm interested to know what you have in mind. Received on Sat Feb 16 2008 - 03:52:10 CET

Original text of this message