Re: Mixing OO and DB

From: Marshall <marshall.spight_at_gmail.com>
Date: Fri, 22 Feb 2008 11:54:40 -0800 (PST)
Message-ID: <eb3aa03d-fad2-41a6-b57c-6161b6ebb095_at_62g2000hsn.googlegroups.com>


On Feb 22, 10:04 am, Robert Martin <uncle..._at_objectmentor.com> wrote:
> On 2008-02-21 20:43:52 -0600, David BL <davi..._at_iinet.net.au> said:
>
> Of course. Class circle is a model of circle-ness. Instances of class
> circle are models of individual circles. Those instances are not
> themselves circles; they are references to (models of) circles. And
> references to subtypes are not themselves subtypes.

This is the same excessive indirection that I complained to Dmitry about. It introduces unimportant distinctions, such as that between "model of a circle" and "circle" and leaves out essential distinctions, such as mutability/immutability.

A model of a circle is a circle is an ellipse. An instance of an immutable circle class is a circle is an ellipse. A pointer to an instance of an immutable circle class   is a pointer to a circle is a pointer to an ellipse.

Values work very simply. Mathematical variables work very simply. First-class variables aka pointers to mutable storage aka references to mutable objects do not work so simply, and it is only with this sort of thing that we run in to substitutability problems.

An instance of a mutable circle class is not an instance of a mutable ellipse class. That's where the problem lies.

> I don't know Date's nomenclature. However the fact that I put two
> variables next to each other, and call one "radius", and the other
> "center", and then I wrap both in a container labled "circle", does not
> mean I have a circle.

What *do* you think a circle is? I mean just a "circle"; not a C++ class
for mutable circles or whatever. Suppose you have a specific circle in mind; what do you have to tell me so that I'll know what circle you mean?

> All I have is a model of a circle.

(Right, you have a circle.)

> I cannot
> roll that container the way I could role a circle. I cannot use a tape
> measure to empirically measure the circumference. I cannot arrange
> little tiny squares within it to approximate the area. I cannot draw
> the container with a compass, nor can I bisect it and measure the
> internal angle of the bisection at a right angle. The container, for
> all it's wonderful ability to *describe* a circle, is not a circle.
> And so that poor container is not a subtype of a similar container that
> happens to describe an ellipse.

Huh? None of the things you describe can be done to circles. You are talking about a drawing on a piece of paper now. You can't use a tape measure on a circle because a circle is an abstraction. You can't measure five either, or tell me what color addition is.

Are you under the impression that the intent of a circle class in a geometric class library is to model pencil drawings on paper?

> Consider three real numbers, x, y, and r. Taken together they
> represent a circle. (3,3,27) represents a unique circle with center at
> (3,3) and radius of 27. Let's say I have two triplets, both with
> values (3,3,27).

You don't have two triplets here; you only have one triplet. let a = (3,3,27)
let b = (3,3,27)
a = b

Here, I just have one triplet. I have two variables, a and b, each of which is bound to the same triplet.

> They both represent the same circle, not two
> independent circles.

Yes; the triplet uniquely specifies a circle.

> Indeed, the triplets are references to the same
> circle.

The two variables are bound to the same triplet, which is to say the two variables refer to the same circle.

> The triplets hold the "address" of the circle in cartesian
> space.

No. The variables hold the value of the circle. The triplet doesn't "hold" anything; it's a value, and values don't hold. Variables hold values.

> The triplets are, for all intents and purposes,
> pointers to circles.

The triplets are not pointers or references; they are values.

> And pointers to subtypes are not themselves subtypes.
>
> > Values are self-identifying. When a variable holds an appearance of a
> > value there is an encoding involved, but that isn't the same as an
> > indirection in the sense of a pointer dereference.
>
> But the value is not a circle. The value *refers* to a circle.

A value is a circle. A circle is a value.

> > I don't understand that at all. In what sense does a class (a compile
> > time definition of a type plus a full or partial implementation)
> > reference something in the problem or solution domain? Let's see you
> > formalise that!
>
> class Person {....};
> Person p("Bob Martin");
>
> The value of p refers to me. The value of p is not me.

Right. That example is correct because the domain of discourse is physical, specifically people. However when we are talking about circles, the domain of discourse is not physical objects any more, but rather abstractions.

int p = 5;

Would you say "the value of p refers to five. The value of p is not five."? You shouldn't. The value of p is five.

Marshall Received on Fri Feb 22 2008 - 20:54:40 CET

Original text of this message