Re: Mixing OO and DB
Date: Wed, 20 Feb 2008 12:05:40 +0100
Message-ID: <1azh2s72p0rfs$.1rg1yas21726e$.dlg_at_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.
>> 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 - 12:05:40 CET