Re: Mixing OO and DB
Date: Wed, 20 Feb 2008 12:05:40 +0100
Message-ID: <1azh2s72p0rfs$.1rg1yas21726e$.dlg@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:
- It is typed: the value has to have the type expected.
- 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.deReceived on Wed Feb 20 2008 - 05:05:40 CST