Re: Mixing OO and DB

On Feb 15, 1:27 pm, David BL <davi..._at_iinet.net.au> wrote:

> I think when I say "substitutability of values" I mean what you call
> in-substitutability, and when I say "substitutability of variables" I
> mean what you call out-substitutability.

I take back my claim that "substitutability of variables" means outsubstitutability.   I think it should encompass both insubstitutability  and out-substitutability.

Therefore I was wrong to suggest that a pointer to a ColouredRectangle variable could be implicit cast to a pointer to a Rectangle variable, because it can lead to subsequent slicing. In the end it's better just to say that subtyping ColouredRectangle from Rectangle doesn't make sense and leave it at that.

If we go back to the much more sensible example of value-type inheritance of circle from ellipse we see that a circle is insubstitutable  for an ellipse, whereas an ellipse is out-substitutable for a circle. That suggests to me that a language must distinguish out parameters from in-out parameters, and therefore passing outparameters  using pointers to variables isn't the right approach.

In the following example an ellipse is out-substitutable for a circle:

    // declaration
    Circle foo();

    // call
    Ellipse e = foo();

I'm not sure I like this terminology of in-substitutable and outsubstitutable.   It seems easier to me to just remember that a circle value is an ellipse value and note that in-parameters narrow whereas out-parameters widen.

One of the reasons people tend to pass out parameters as pointer arguments is to support multiple out parameters. I rather like the idea of a language that supports a tuple syntax for multiple out parameters. Eg

    // definition
    (Circle c, int x) foo()
    {

        // Can assign named out-parameters c,x
        // No need for a 'return' statement!
        c = Circle( Point(0,0), 10 );
        x = 1;

    // call
    (Ellipse e, int x) = foo(); Received on Fri Feb 15 2008 - 10:12:22 CET