Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Thu, 14 Feb 2008 05:28:34 -0800 (PST)
Message-ID: <f924e378-44f0-4d4f-95ef-d4e921353140_at_e10g2000prf.googlegroups.com>


On Feb 14, 7:57 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
> > On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:
> >> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
> >>> Objects are said to have identity, state and behavior. The idea that
> >>> an object can (always) be thought of as a (data) variable that can be
> >>> assigned a (data) value reveals a complete lack of understanding of
> >>> OO.
> >>> Bob's confusion between the concepts of object state versus object
> >>> value also leads him to misunderstand the significance of
> >>> encapsulation in the context of OO.
>
> >> I hate to agree with Bob Badour, but the notion of object is indeed
> >> superfluous. It is enough to have value, type, variable. Type has behavior.
> >> Variable has state. Identity can be attributed to a variable (the name of)
> >> or a value (the type of) or a type (the behavior of, or the name of, if
> >> named). What is specific to OO, that polymorphic values have identities of
> >> the corresponding specific types, which makes dispatch possible.
>
> > You appear to agree with Bob, but nothing could be further from the
> > truth.
>
> > Have you read the characterisations of value, variable and type by
> > C.Date? They are very different to your above descriptions.
>
> > value : doesn't exist in time or space. Immutable
> > variable : can be assigned a value
>
> Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
> not as an operation defined, but rather as:
>
> variable : has a value

I checked C.Date's wording. He says a variable is a holder for the appearance of a value, and a variable can be updated - meaning that the current value of the variable can be replaced by another value.

> > type : set of values plus operations on those values
>
> > C.Date ignores the Liskov Substitution Principle (LSP) and states that
> > a circle is an ellipse, and that a coloured rectangle cannot be a
> > subtype of a rectangle.
>
> Well, circle is indeed an ellipse. It is just so that the implication
>
> circle is a ellipse => circle is substitutable for ellipse
>
> is wrong.

I think you need to qualify that. Using C.Date's definitions of type and variable, a circle value is substitutable for an ellipse value, whereas substitutability doesn't apply for variables.

For an OO concept of type, substitutability of an object (ie "variable") depends on whether the ellipse class provides any mutative methods that could allow a circle object to stop being a circle. Of course one generally wants to be able to assign any possible ellipse value to an ellipse variable so IMO this example inevitably breaks LSP. It is interesting that if a language were to properly support value types then we actually would want to *drop* state in derived classes because specialisations give you less degrees of freedom, not more. I have wondered whether a language along the following lines would be appropriate:

type Rect
{

    int area { return width*height; }
    int width;
    int height;
};

type Square : Rect
{

    int height { return width; }
};

type UnitSquare : Square
{

    int width { return 1; }
};

void foo()
{

    UnitSquare s;
    int a = s.area;
}

I would hope that through in-lining the compiler simply initialises a = 1.

> Further a coloured rectangle can be substitutable for rectangle
> in some context.

I think you need to qualify that as well, because now it's the reverse: substitutability makes sense for variables, but not for values!

C++ programmers refer to the slicing problem when an upcast of a value slices away some of its state. A coloured rectangle value can easily have its colour sliced away.

> Talking about substitutability (and anything else) one
> should not mix sets (types) and members of (values). C.Date and B.Liskov
> apply "is" do *different* things.

>
> > Given Date's definitions of variable and type, his conclusions are
> > sensible. I recommend all OO programmers read C.Date's work on sub-
> > typing.
>
> I agree.
>
> > In my opinion an OO language should properly support value-types in
> > the way described by Date.
>
> Oh, yes. Moreover by-reference-semantics is secondary to
> by-value-semantics. It is impossible to create a consistent
> everybody-has-identity system. Identity itself is just a value.
>
> > Unfortunately I don't know of any that
> > do. Of course it should also support the conventional OO notion of
> > typing which is based on contractual guarantees of behavior and hence
> > leads to the LSP for sub-typing.
>
> Well, LSP program is utopian. Substitutability cannot be achieved by such
> rough means. As for contracts, your wording leaves an impression that
> contracts are somehow unnecessary for the behavior of "value-types." (I
> cannot agree with that)

I guess I need better words. Note however that I don't think "behaviour" in the sense of conventional OO is relevant to valuetypes.   Values are immutable and all updates to variables are assignments. A variable doesn't have a chance to exhibit behaviour! At a certain level of abstraction all operators defined on a value type can be assumed to act on pure inputs and return pure outputs. Received on Thu Feb 14 2008 - 14:28:34 CET

Original text of this message