Re: Overring function and its returned type

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Fri, 09 Nov 2012 22:10:05 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> I will also try to workaround with an overloading instead of an  
> overriding, but I'm afraid of getting into a mess with this solution.  
> Will choose which cause the less troubles, and although the  
> postcondition+conversion solution looks like bloat, I believe that's  
> still the safest. I will still try both to really get an idea…

Two attempts, with a comment comparing both at the end.


First attempt
=============

Something I tried, which lead to an interesting issue. I don't know if  
GNAT is right or wrong, this will require a careful reading of the RM.

Replace `P3` spec with:


        package P3 is

           type R is new P1.R with null record;
           type T is new P1.T with null record;

           overriding
           function F
             (E : T)
              return P1.R'Class
              with Post'Class =>
                 F'Result in R'Class;

           -- Not a primitive operation.
           function F
             (E : T'Class)
              return R'Class
              is (R'Class (P1.T (E).F));
        end;


And a use case, which fails:


        A : P3.T;
        B : P1.R'Class := A.F;
        C : P3.R'Class := A.F; -- Fails here


That's C's assignment which fails. Seems GNAT cannot resolve it figure it  
refers to the second `F` function (it does not even complains about an  
ambiguity). Will have to look at the RM for it. I feel this should be OK  
and could be resolved as expected, but may be the RM states otherwise.

The second `F` function cannot be a primitive, due to its “inline”  
expression.


Second attempt
==============

Another way to solve it:


        package P3 is

           type R is new P1.R with null record;
           type T is new P1.T with null record;

           overriding
           function F
             (E : T)
              return P1.R'Class
              with Post'Class =>
                 F'Result in R'Class;

           not overriding
           function F
             (E : T)
              return R'Class;
        end;

        -- ----------------------------------------

        package body P3 is

           overriding
           function F
             (E : T)
              return P1.R'Class
           is
              X : R;
           begin
              return X;
           end;

           not overriding
           function F
             (E : T)
              return R'Class
           is begin
              return R'Class (P1.T (E).F);
           end;
        end;


And the sample use case:


        A : P3.T;
        B : P1.R'Class := A.F; -- Fails here
        C : P3.R'Class := A.F;


Assignment to `B` is considered ambiguous, but that's not an issue, as  
only the case corresponding to the assignment to `C` is expected. Anyway,  
the case of the assignment to `B` can be solved this way:


        B : P1.R'Class := P1.R'Class'(A.F); -- Resolved ambiguity


Comparing both
==============

What's nice with the first attempt, is that what's returned is explicitly  
shown in the spec. What's nice with the second attempt, is that it works  
(good point, cheese), and that it's a primitive (if ever that matters  
really), but as a cons, it is not as explicit as in the first attempt.

May be the best solution is to do as in the second attempt, and give the  
second `F` function, a comment “specifying” the returned result is exactly  
the same as the with the first `F`, expect explicitly of type `R'Class`.

That's not as clean as one could expect, but at least I don't see it as  
presenting any potential issues in the case where `P1` holds a primitive  
with a predicate referring to `F`. The human reader could infer such a  
predicate would applies to the second `F` function too, as long as it is  
clear enough both returns the same thing, except for their explicit types.  
The compiler won't know, but the human reader will.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University