Re: Mixing OO and DB

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Wed, 20 Feb 2008 12:05:40 +0100
Message-ID: <1azh2s72p0rfs$.1rg1yas21726e$.dlg_at_40tude.net>


On Tue, 19 Feb 2008 18:15:31 -0800 (PST), David BL wrote:

> On Feb 19, 7:05 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:

>> On Mon, 18 Feb 2008 19:09:48 -0800 (PST), David BL wrote:
>>> On Feb 19, 12:41 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
>>> wrote:
>>>> On Mon, 18 Feb 2008 05:59:39 -0800 (PST), David BL wrote:
>>>>> I disagree. I'm talking about algorithms that are implicitly
>>>>> parameterised over various value-types.  LSP isn't even applicable for
>>>>> value-types.
>>
>>>> How so? LSP defines behavioral notion of type as set of provable
>>>> predicates. This clearly includes your parametrized types. The parameters
>>>> are subjects of type substitution. It is pure LSP.
>>
>>> I have a more specific understanding of LSP.   Let an object mean a
>>> variable that has identity, state and behavior, but isn't assumed to
>>> hold a value.
>>
>> Wait here. Object's state + identity = its value. As I said before, value
>> semantics is fundamental in the sense that a stateful one is derived from
>> it.

>
> Saying
>
> Object's state + identity = its value
>
> doesn't seem well defined. Does the object's state ever encompass
> following a pointer? What about objects with OS resource handles
> like socket handles or mutex handles? How do you delineate its state?

Resource value /= value of its handle. They are of *different* types.

(You have a mental block about [fictional] equivalences of values. Whatever equivalence between the resource and its handle might exist, it is not an immanent thing. It is simply an implementation to be *first* proven to be correct. Claiming the equivalence in advance is putting a cart before the horse.)

>> Right, this is exactly what you said above "subtyping can mean
>> anything you want it to mean." It is not the compiler's business.

>
> Can you define precisely what rules the compiler uses for
> substitutability? Whatever the rules are, surely they are well
> defined?

Yes. There rules are two:

  1. It is typed: the value has to have the type expected.
  2. S is a subtype of T in the operation f, if both types have this operation defined.
>>> Consider the following function that inverts a matrix parameterised in
>>> field T for the type of the matrix elements.
>>
>>>     template <class T> Matrix<T> Invert(Matrix<T> x)
>>
>>> Invert<R> is valid because R is a field, whereas Invert<Z> is not
>>> valid because Z is not a field.
>>
>>> According to C.Date's definition of sub-type, Z is a sub-type of R.
>>> This definition of sub-type doesn't allow you to assume you can
>>> replace R with Z in Invert<R> to yield Invert<Z>.
>>
>> I would say it differently: Z is not a subtype of R in the operation Invert
>> => Matrix Z is not a subtype of Matrix R, again, in Invert, provided a
>> definite implementation of.

>
> I don't see how it matters. The function Invert<T> is parameterised
> in T no matter how you say it.

So? Z does not belong to T with Invert:T->T. You cannot put Z there, it is a type error.

>>> You are saying there is no difference in C.Date's notion of sub-
>>> typing, versus a definition of subtyping that allows you to substitute
>>> the type in a parameterisation.   I cannot understand that.
>>
>> We agree that type = values + operations. When we substitute a type, we do
>> its operations as well (where covariant). A simple consequence is that Z
>> which does not have Invert cannot be substituted where Invert operation is
>> expected. The notion of subtype is still same in the sense of conversions.
>> Date's subtype Z is R - Invert. He disallowed this operation. In some
>> contexts it will go, in others it will not.

>
> On the contrary, Date assumes that Z inherits real-valued
> multiplicative inverses from R. He doesn't disallow any operations.
> He states very clearly that a subtype always has a *superset* of the
> supertype's operations.

This is sloppy. Remember that Invert is defined as:

   Invert : T -> T

When you say "inherit" you have to clarify where Z gets substituted. If you substitute it only under the first T it is not an inheritance required for a field. In effect the field's Invert is disallowed. The case is very clear.

>>>> It cannot be converted! For out-substitutability of Rectangle, it is out
>>>> ColouredRectangle which is converted to Rectangle.
>>
>>> So you're saying slicing away the colour is respectable?
>>
>> Yes when you pass it as an in-rectangle. The latter has no colors. Maybe an
>> example would help.

>
> I find it unacceptable that the compiler will silently generate code
> that slices away part of a value.
>

> I think this will only help average programmers become bad
> programmers. It seems too easy to create a confusing mess!

In order to be able to say that, you have to show an inconsistency. I don't see any. One value is converted to another. Where is a problem?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Wed Feb 20 2008 - 12:05:40 CET

Original text of this message