Re: Mixing OO and DB

On Feb 15, 8:20 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
> On Thu, 14 Feb 2008 20:27:52 -0800 (PST), in

> > Consider the function 1/x which is axiomatically defined on (nonzero)
> > reals but not the integers. That suggests that Z is not a subtype of
> > R. However consider
>
> > float Invert(float x) { return 1/x; }
>
> > That doesn't stop us calling Invert(2) even though 2 is only an
> > integer. We still get a float result!
>
> I think there is a confusion here. Note that invert as an operation deals
> with a tuple float x float:
>
> Invert : float -> float
>
> Now, the question is where are you going to substitute ints?
>
> 1. In the first appearance of float
> 2. In the second one (result)
> 3. In both
>
> Depending on that Invert will become inheritable or not. I.e
> substitutability is not only parameter mode depending, it also depends on
> the concrete parameters too. (For the sake of genericity, results are
> parameters.)

I'm aware of the three conceivable options, but I'm quite clear in my mind that the system should only support the narrowing of inparameters  and widening of out-parameters. Therefore, as Invert() has been written (1) is the only option. If you want option (3) then you need to explicitly write a parameterised function. Eg

    template <class T> T Invert(T x) { return 1/x; }

However it seems inappropriate to allow Invert<int>().

When C.Date talks about value substitutability he doesn't mean you can pick any function you like and substitute a sub-type in place of a super-type throughout the function. Doing so gives you a *distinct* function and the system is not allowed to guess that it is meaningful to do so. If you wanted this to be valid, then it would greatly restrict possible sub-typing relationships and that limits code reuse. In particular, it would no longer be possible to treat Z as a subtype of R. Probably some mathematicians would think that is sensible since the system Z doesn't inherit the axiom for existence of multiplicative inverses from R. However, I prefer the idea that algorithms are parameterised explicitly where appropriate, and only let the system perform implicit type conversions on in/out parameters or assignments.

[snip] Received on Fri Feb 15 2008 - 17:46:54 CET