From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c7c302806c75a91b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.66.75.39 with SMTP id z7mr14847924pav.26.1351801789969; Thu, 01 Nov 2012 13:29:49 -0700 (PDT) Received: by 10.68.225.102 with SMTP id rj6mr801021pbc.4.1351801789951; Thu, 01 Nov 2012 13:29:49 -0700 (PDT) Path: 6ni56510pbd.1!nntp.google.com!kr7no28454974pbb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 1 Nov 2012 13:29:49 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <13ce31f3-34c8-4e08-b45f-cbed9e4ffefe@googlegroups.com> Subject: Re: Design by contract and control inversion From: Adam Beneschan Injection-Date: Thu, 01 Nov 2012 20:29:49 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-11-01T13:29:49-07:00 List-Id: On Wednesday, October 31, 2012 12:28:33 PM UTC-7, Hibou57 (Yannick Duch=EAn= e) wrote: > Hi all,=20 >=20 > I wondered if there are known idioms to express predicates for callbacks,= =20 > which may be via access to subprogram or interface/tagged types. Control = =20 > inversion seems to not be easily mixable with design by contract. An =20 > example to make it clearer.=20 >=20 > Say a type `T` has a method with expect either an access to subprogram or= =20 > an interface:=20 >=20 >=20 > type T is private;=20 >=20 > procedure Expect_Handler=20 > (Me : T;=20 > Handler : not null access=20 > procedure (Context : T));=20 >=20 > type H is interface;=20 >=20 > procedure Handle=20 > (Me : H; Context : T)=20 > is abstract;=20 >=20 > procedure Expect_Handler=20 > (Me : T;=20 > Handler : H'Class);=20 >=20 >=20 > Now let say the type `T` has different properties, and one is always =20 > `True` when no handler in currently invoked, and always `False` when an = =20 > handler is currently running (which may be nesting), so that from inside = =20 > of any `Handle` interface method of subprogram, then that property will = =20 > always be `False`, and that I want it to be part of the specification.=20 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. =20 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