Re: Design by contract and control inversion

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

Le Fri, 02 Nov 2012 17:45:33 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:

> On Wednesday, October 31, 2012 1:28:33 PM UTC-6, Hibou57 (Yannick  
> Duchêne) wrote:
>> Hi all,
>>
>> I wondered if there are known idioms to express predicates for  
>> callbacks,
>> which may be via access to subprogram or interface/tagged types.
>
> Hm, it seems to me that you could have an intermediate/pass-through  
> handler.
> (It would be rather limited, unless you make pre-/post-condition  
> parameters... and if you do that it could get cumbersome quick.)
> [NOTE: Not compiled or checked, just brainstorming/psudocode.]
>
> Type Obj_Handle is not null access Object'class;
> Type Handler is Access Procedure ( A, B : Integer; C : Obj_Handle );
>
> -- this version applies the same preconditions to all handlers.
> Procedure Intermediate (A, B : Integer; C : Obj_Handle; D : Handler)
>    with Inline, pre => A > 0 or B in positive'Range;
>
> Procedure Intermediate (A, B : Integer; C : Obj_Handle; D : Handler) is
> begin
>    D( A, B, C );
> end;
>
> To extend these with pre-/post-conditions we could add another type and  
> another parameter to the handler.
>
> Type Condition is access function( P : Parameter ) return Boolean;
> Type Conditions is record
>   Pre, Post : Condition;
> end record;
>
> -- This version applies the psudo-pre/post-conditions, as supplied.
> Procedure Intermediate (A, B : Integer; C : Obj_Handle; D : Handler; E :  
> Conditions) with inline,
>  pre  => (if condition'(E.Pre)  /= Null then E.Pre),
>  post => (if condition'(E.Post) /= Null then E.Post);
> Procedure Intermediate (A, B : Integer; C : Obj_Handle; D : Handler; E :  
> Conditions) is
> begin
>    D( A, B, C );
> end;
>
>
> Or something like it, no?

Yes, that could do the trick. But this is a bit too much for a  
specification, and even could not find a place in a specification, as Ada  
2012 does not allow procedures in package specs (just functions), unless  
I'm wrong with it.

Your idea made me think how again the interface type is the best: just  
give the precondition you gave to `Intermediate`, to the handler method of  
the interface type.

The only thing which still make me wish I could have something like this  
with access to sub‑program, is that access to sub‑program can get an  
access to an inner sub‑program (as long as it not to be stored, which is  
the case here); you can't do this with an interface type, as a type  
defined in a nested scope is not usable (an issue similar to the access  
level with named access type).

By the way, I've dropped the initial design which was not safe enough.  
Instead of adding preconditions everywhere, I will have an object which  
returns two kind of objects, one for read access and one for write access,  
and the relevant preconditions to ensure you can't have both read and  
write access at the same time, will be only on the two functions returning  
these two views. That's safer and simpler. I will just have to resign to  
not have any‑more an object exposing the two views (I initially wanted too  
much).


-- 
“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