Re: Design by contract and control inversion

[Adam Beneschan <adam@irvine.com>]

On Wednesday, October 31, 2012 12:28:33 PM UTC-7, 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. Control   
> inversion seems to not be easily mixable with design by contract. An   
> example to make it clearer. 
> 
> Say a type `T` has a method with expect either an access to subprogram or   
> an interface: 
> 
> 
>      type T is private; 
> 
>      procedure Expect_Handler 
>        (Me : T; 
>         Handler : not null access 
>            procedure (Context : T)); 
> 
>      type H is interface; 
> 
>      procedure Handle 
>        (Me : H; Context : T) 
>         is abstract; 
> 
>      procedure Expect_Handler 
>        (Me : T; 
>         Handler : H'Class); 
> 
> 
> Now let say the type `T` has different properties, and one is always   
> `True` when no handler in currently invoked, and always `False` when an   
> handler is currently running (which may be nesting), so that from inside   
> of any `Handle` interface method of subprogram, then that property will   
> always be `False`, and that I want it to be part of the specification. 


Let me see if I understand correctly.  You have a package that defines
T and some operations on T, including Expect_Handler (which in real
life would probably be some useful operation on T that could call the
callback).  (1) You want human users of the package to know that, when
they write the procedure My_Handler that will be passed to
Expect_Handler, that My_Handler can count on a particular property of
T being false.  (2) You also want users to know that they can count on
that property of T being true at other times.

Well, the first thing to do is to write a comment in your package
specification saying so.  

It seems that you want something more formal than just a comment,
though.  While I can understand why you'd want to do this, I don't
think it's feasible in Ada.  As far as #1 is concerned, Ada doesn't
have a syntax for adding preconditions or postconditions to an
access-procedure parameter.  I can see how this feature might be
useful, so that when Expect_Handler calls Handler.all, the compiler
would generate the checks before and/or after the call.  But it
doesn't exist right now.  As for #2, I can't imagine any language ever
supporting anything like this, since I can't even imagine how one
would express the concept of "other times" in a computer language.

My concern is that you're trying to come up with a "solution", but
you're thinking of solutions that, in my opinion, will make the
specification more obscure to a reader.  What's the gain in that?  To
me, "design by contract" is more of an approach to software design,
rather than a language feature; language features can help support
this design approach, but the language features are not themselves
"design by contract".  (Thus, I think your earlier statement that
"control inversion seems not be easily mixable with design by
contract" is a fallacy; I think they go together just fine, it's just
that we don't yet know how to add language support for it yet.)

To me, the important thing is that you have the contract in mind when
you design the package, and you express it in a way so that other
programmers who are using this package will know what conditions are
expected of their code, and what conditions they have a right to
expect from yours.  If the only way to do that is with comments, then
do it that way.  But since that's the important thing, trying to come
up with a tricky or idiomatic "solution" to your problem would tend to
defeat your purpose more than to serve it.  Unless, that is, there's
some other purpose you really, really need to accomplish.  If so, then
you'll probably have to provide more specific details about the code
you're trying to design.

Just my opinion.....  I'm sure others will differ.

                                -- Adam