Re: Mixing OO and DB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 14 Feb 2008 13:24:32 -0400
Message-ID: <47b47951$0$4028$9a566e8b_at_news.aliant.net>


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.

>>>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.

It is always true that the addresses of a supertype's variables are a subtype of the addresses of a subtype's variables. People like David bend themselves out of shape trying to apply Liskov in reverse.

>>It is just so that the implication
>>
>> circle is a ellipse => circle is substitutable for ellipse
>>
>>is wrong. Further a coloured rectangle can be substitutable for rectangle
>>in some context. 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.

I disagree. D&D address Liskov directly.

>>>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.

I see we can all agree on something.

>>>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.

Not only is it secondary, the reference reverses the sub and the super.

[snip] Received on Thu Feb 14 2008 - 18:24:32 CET

Original text of this message