Re: Design by contract and control inversion

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

Le Thu, 01 Nov 2012 21:29:49 +0100, Adam Beneschan <adam@irvine.com> a  
écrit:
> 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.

Yes, that's it.

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

I more hardly see the same with the interface type (instead of an access  
to sub-program).

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

I tried, and when I saw this was too difficult, I gave up. I ended with  
the solution posted elsewhere in this thread, which is to use another type  
for the parameter passed to the handler. But that created some other  
issues worth to be discussed (will be back with it later).

>  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".

Not sure I've understood, but I will try. The comment seems interesting.

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

I did it that way. For the time, “other programmers” is just me (some  
others may have opportunities to see it, but that's for a far later time).

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

Sometime it's not easy to see if you just fail to properly setup a design  
which may be good, or if it's just the design which is wrong. At least,  
that's good experiments to remember about. I'm currently facing a similar  
question, trying to mimic SML's signatures using Ada generics and  
interface types.

I may post part of the specification in this thread, to request people for  
comments. Will be useful to know if whether or not it's clear enough and  
understandable (just don't expect anything wonderful, that's a stupidly  
simple thing apart of the question raised here).


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