Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Thu, 14 Feb 2008 20:59:11 -0800 (PST)
Message-ID: <a35b5e8c-2d78-4624-b1c1-cc2c8967cb19_at_i12g2000prf.googlegroups.com>


On Feb 15, 2:24 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> JOG wrote:
> > On Feb 14, 10:57 am, "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.
>
> Don't be a hater. You can love to disagree with me without hating to agree.
>
>
>
>
>
> >>>>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
>
> >>>type : set of values plus operations on those values
>
> >>>C.Date ignores the Liskov Substitution Principle (LSP) and states that
>
> Actually, D&D address Liskov directly. One wonders whether David
> bothered to read them. If he did, one can only conclude he has
> difficulty comprehending written english.

C.Date discusses LSP but discounts it as inapplicable to his notion of subtyping - which has to do with *value* substitutability. LSP concerns substitutability of objects, and Bob will be the first to tell you that these are variables (not values).

> >>>a circle is an ellipse, and that a coloured rectangle cannot be a
> >>>subtype of a rectangle.
>
> >>Well, circle is indeed an ellipse.
>
> And a coloured rectangle is a composition of a colour and a rectangle.
> Only an ignorant moron would demand compositions be subtypes of their
> components. Duh! ::rolls eyes::
>
> > I /believe/ what Date would say (and its certainly what I would say
> > even if he has not) is that a set of points has the properties
> > qualifying it as a "circle" as well as those qualifying it as an
> > "ellipse". Two parallel views of the same underlying data.
>
> Actually, the more interesting thing Date said is the addresses of
> ellipse variables are a subtype of the addresses of circle variables.
> They are a subset of the addresses where one can store a circle value,
> and they have a superset of the (assignment) operations.

Bob seems to have neglected the fact that variables can be read (as well as written), which means it isn't true that a pointer to an ellipse variable is a pointer to a circle variable.

Example

    float GetArea(Circle* c)
    {

        return PI*c->GetRadius()*c->GetRadius();     }

    Ellipse e;
    float a = GetArea(&e); // oops

> It is always true that the addresses of a supertype's variables are a
> subtype of the addresses of a subtype's variables.

Not true.

[snip] Received on Fri Feb 15 2008 - 05:59:11 CET

Original text of this message