Re: Mixing OO and DB
Date: Tue, 19 Feb 2008 11:05:07 +0100
Message-ID: <5kbgaz8or0du.7c9cseb27qah.dlg_at_40tude.net>
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.
> 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.
> 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.
> 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.
>> 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.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Tue Feb 19 2008 - 11:05:07 CET