Re: Mixing OO and DB

From: David BL <davidbl_at_iinet.net.au>
Date: Sun, 17 Feb 2008 21:56:18 -0800 (PST)
Message-ID: <92597ead-bfd4-43d2-8ba0-d7d78d0e13a4_at_h11g2000prf.googlegroups.com>


On Feb 16, 9:03 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Fri, 15 Feb 2008 18:52:10 -0800 (PST), David BL wrote:
> > On Feb 15, 8:13 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> > wrote:
> >> On Fri, 15 Feb 2008 01:12:22 -0800 (PST), David BL wrote:
> >>> On Feb 15, 1:27 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> >>>> I think when I say "substitutability of values" I mean what you call
> >>>> in-substitutability, and when I say "substitutability of variables" I
> >>>> mean what you call out-substitutability.
>
> >>> I take back my claim that "substitutability of variables" means out-
> >>> substitutability. I think it should encompass both in-
> >>> substitutability and out-substitutability.
>
> >>> Therefore I was wrong to suggest that a pointer to a ColouredRectangle
> >>> variable could be implicit cast to a pointer to a Rectangle variable,
> >>> because it can lead to subsequent slicing.
>
> >> An important node. Pointer is a data type distinct from the data type of
> >> what it is supposed to point to. What you probably meant is that there
> >> exists a mapping: f : ColouredRectangle -> Rectangle.
>
> > Yes that mapping exists. It is surjective but not injective. Not
> > injective means it isn't information preserving (because distinct
> > coloured rectangles map to the same rectangle when the colour is
> > sliced away). IMO for implicit conversions to be applicable, such a
> > mapping must be injective (but not necessarily surjective).
>
> >> Which in dreadful C++
> >> notation looks like
>
> >> *(Rectangle *)&
>
> >> (a composition: &, casting and *). In a decent language, which C++ is not,
> >> the operation * should not be allowed for all types indiscriminately. That
> >> makes optimization quite difficult. What if Rectangle "physically exists"
> >> on a different machine in a DB? How can I get its pointer? What is this
> >> pointer? etc. Getting rid of data, also eliminates hard-wired data things
> >> like pointers. Instead you get behavior of some objects referencing others.
>
> > I don't think I follow. Are you saying
>
> > *(Rectangle *)&
>
> > amounts to slicing and you can blame the pointer indirection - ie
> > operator*() ?
>
> I mean that you need not to resort to pointers or more generally to
> internal representation in order to say that Rectangle value can be
> obtained from a ColouredRectangle one.

Agreed. However note firstly that I introduced pointers in order to talk about substitutability of variables. Secondly, I don't deny it's *possible* to obtain a Rectangle value from a ColouredRectangle one. I don't think this should ever happen implicitly.

> Further the programmer should define the conversion, if that cannot be
> generated by the compiler or is inappropriate.

> >>> In the end it's better
> >>> just to say that subtyping ColouredRectangle from Rectangle doesn't
> >>> make sense and leave it at that.
>
> >> But there exists a mapping between them, which makes possible for
> >> ColouredRectangle to be an extension of Rectangle. In practical terms it
> >> means that ColouredRectangle can be out-substitutable for Rectangle:
>
> >> Give_Me_One : <something> -> Rectangle
>
> >> (this case you considered for circle/ellipse later)
>
> > That doesn't change my opinion that sub-typing is inappropriate in
> > this case.
>
> Why, it is perfectly OK. Consider a factory of rectangles. There is nothing
> wrong in generalization. It is just so that generalization is compatible
> with inheritance of out-operations, while specialization is with
> inheritance of in-operations.

I discussed my reason in another post to you.

> >> Ah, this is a crucial point. Circle value is not an ellipse value. These
> >> have different types. It is only so that there exists a mapping which gives
> >> you an ellipse value from any circle value.
>
> > It depends on what "is" means. Using the example of the integers and
> > reals: As mathematical systems it is reasonable to say the integers
> > is not a sub-type of the reals. However it is true that the set of
> > integers is a *subset* of the set of reals.
>
> [I answered this in another post. Z is a ring, R is a ring too. One can
> inherit a ring Z from R]
>
> > Perhaps the C.Date approach needs a different terminology (ie than
> > subtype) to avoid this confusion. When Date says integers is a sub-
> > type of reals, he means for example that nonzero integers have
> > inherited real-valued multiplicative inverses. In mathematical
> > definitions of integers that's inappropriate, but for software
> > development I need to see a good reason to disallow it. Can you
> > provide one?
>
> No, it is OK. That is a specialization. You constrain a type upon
> subtyping. The constraining manifests by loosing some operations. There is
> nothing wrong with that. But also there is nothing wrong with
> generalization. And also there is nothing wrong with mixed cases.

With C.Date's notion of sub-type you always inherit all operations from the super-type. You can add more operations, but cannot lose any (or redefine any).

For example, if 16 bit integers subtype 32 bit integers, then 16 bit integers inherit addition modulo 2^32 (stored in a 32 bit result). That doesn't stop 16 bit integers from introducing addition modulo 2^16 as a distinct operator. Overloading of operator+ is just a syntactic issue.

> > I don't think you need the mapping to give an ellipse value from a
> > circle value. I would rather say the set of circle values is a subset
> > of the set of ellipse values.
>
> Disagree, that would heavily limit the system, and likely make it
> inconsistent. The only sense in which circle value should ellipse value is
> to keep the internal representation same. Why should I care?

It doesn't limit the system in the way you suggest. You can have many different representations of the same (logical) value. For example polar versus cartesian representation of a point.

I can imagine a language with the same goals for run time efficiency as C++, and the following function can be compiled for many different implementations of Rectangle, including specialisations like Square or UnitSquare.

    float GetArea(Rectangle r)
    {

        return r.Width() * r.Height();
    }

> >> As for subtyping, to me, it is just a relation between types. I don't
> >> expect it to deliver substitutability. It cannot. What it can and should,
> >> is to help me to deal with the problem.
>
> > Can it? I'm interested to know what you have in mind.
>
> There are many cases where languages could be safer. For example:
>
> 1. multiple dispatching should ensure overriding of all cross variants
> (dispatch may not fail).

I wonder whether dynamic dispatch is only relevant to the LSP notion of sub-typing, ie not to value types. Perhaps not, because union value-types seem to need it.

> 2. construction model shall be sane, i.e. allowing dispatch from
> constructors/destructors.

This doesn't seem appropriate for value-types. C.Date uses the term "selector" instead of constructor as a reminder that it's only purpose is to specify a value.

> 3. there should be an operation extension model, rather than override-whole
> only.

Not sure what that means.

> 4. no re-dispatch allowed

What's re-dispatch?

> 5. classes of all types, including small ones of value-semantics (like
> Boolean and Integer)

Seems like a good idea.

> 6. dynamically constrained types (light-weight classes)

So types are not necessarily a static (compile time) concept?

> 7. abstract interfaces for anything, including member variables, arrays,
> pointers.

Not entirely sure what that means exactly.

> 8. interface inheritance from concrete types

You can inherit the interface, and only the interface from a concrete type? Sounds interesting, but what does it mean for the principle that details depend on simple abstractions, not vice versa?

> 9. supertyping of concrete types

That means different things for different notions of sub-typing. Received on Mon Feb 18 2008 - 06:56:18 CET

Original text of this message