Re: Mixing OO and DB

On Feb 20, 8:05 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> 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.)

You didn't answer my question. How do you define an object's state when it contains pointers or handles?

Here's an example

class X
{
public:

    X() { p = new int(0); }
    ~X() { delete p; }
    int Get() const { return *p; }
    void Set(int x) { *p = x; }
private:

    int* p;
};

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

I thought we agreed type = set of values + operations. What does it mean to say an operation is 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.

Agreed. I'm just responding to your comment "I would say it differently". My original statement was correct and was exactly the point I wanted to make. I didn't want to explain why you can't replace R with Z in Invert<R> to yield Invert<Z>. I only wanted to point out that C.Date's notion of subtyping doesn't imply it.

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

C.Date made it very clear that subtyping (only) allows for value substitutability. I found nothing sloppy in his exposition.

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

Please see my recent response to Robert Martin. Received on Thu Feb 21 2008 - 06:42:44 CET