Re: Mixing OO and DB

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?

> > In my mind LSP is inappropriate for value-types because it is
> > concerned with variables rather than values.
>
> Again, we can consistently render any referential / state / identity
> semantics into pure values. These might be in some cases incomputable, but
> this plays no role for a formal system. Thus I can use only one notion of
> type and subtyping for all cases.
>
> >>> That's not formal enough for me. It sounds like sub-typing can mean
> >>> anything you want it to mean.
>
> >> Right, it has to be this way. If I want to make square a subtype of train
> >> traffic, it is my business. I should provide the implementations of the
> >> corresponding operations and that is.
>
> > But subtyping affects what the compiler will and won't allow.
> > Obviously you need to specify that. In the process you are defining
> > the semantics of sub-typing.
>
> 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?

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

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

> >> 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! Received on Wed Feb 20 2008 - 03:15:31 CET