Re: Mixing OO and DB
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
> > 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.
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.
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