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,ec06888ca495a8ff X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns14feed!worldnet.att.net!attbi_s21.POSTED!53ab2750!not-for-mail From: "Jeffrey R. Carter" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Newbie question: Implementing a callback mechanism with Ada 83 References: <1171136299.920852.179650@v33g2000cwv.googlegroups.com> <1171230053.064136.26460@v33g2000cwv.googlegroups.com> In-Reply-To: <1171230053.064136.26460@v33g2000cwv.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <7ySzh.271637$aJ.253761@attbi_s21> NNTP-Posting-Host: 12.201.97.213 X-Complaints-To: abuse@mchsi.com X-Trace: attbi_s21 1171256579 12.201.97.213 (Mon, 12 Feb 2007 05:02:59 GMT) NNTP-Posting-Date: Mon, 12 Feb 2007 05:02:59 GMT Organization: AT&T ASP.att.net Date: Mon, 12 Feb 2007 05:03:00 GMT Xref: g2news2.google.com comp.lang.ada:9269 Date: 2007-02-12T05:03:00+00:00 List-Id: benibilme@gmail.com wrote: > > What I wanted to achieve is to decouple the packages which are > responsible for the handling of specific events. The initialization of > each specific package would register for the events that it cares > about and only become dependent to the event manager package. Event > manager package would provide the interface for registering callbacks > and the static data for the events, firing an event and removing a > registration etc. A package that monitors a state or an event fires a > defined event in the event manager package with the dynamic data and > event manager module would call successively the registered callbacks > in the different packages which are interested in the event. That was > my intention. As a matter of fact that is a classic solution for event > driven programs that I often use when I code with C. It adds one level > of indirection and breaks the explicit coupling between the event > generators and handlers. It is just a simple publish and subscribe > paradigm. I present a very quick implementation of this module in C > below. I wanted to implement this module in Ada 83 which I am failed > to do. What you're describing here is more an implementation than a description of what you have to do. But to my mind, what you achieve through such an approach is not a reduction in coupling, but an increase. The events and their handling subprograms must be coupled in such situations. However, it is structural coupling to have package A call subprograms in package B; it is control coupling to have package B give package A data (subprogram access values) that determine what actions package B takes. > Of course I can solve my problem without this kind of capability. It > will be brute force solution and according to me an ugly solution. > For example when an event occurs, the module that detected the event > has to call the subprograms in different packages that are interested > in the event. The packages will be tightly coupled to each other. The > package that triggers the event has to know the packages and the > subprograms that interested in the event. I can see the Ada 83 > reasoning. Yes, the code will be more readable maybe and statically > provable but very very verbose and inflexible. At least with my little > Ada knowledge, that is what I can foresee right now. I'm not prepared right now to wade through a bunch of C code for c.l.a. Besides, I'm not interested in how you would do something in C, but more in what you're trying to accomplish, so I can comment on something I do know, which is a good way to implement that in Ada. My personal bias is to avoid the use of access types and values whenever possible, and to hide them when not. What you describe here is a static relationship between events and their handling subprograms, and then you say that a static solution to this static problem is something you consider "ugly". To my mind, a dynamic solution to a static problem is unnecessary complexity; it violates the KISS principle and is ugly. Further, you think the static solution will be easier to read and more likely to be correct, but would prefer a less readable solution that is more likely to be incorrect. I find that incomprehensible. SW engineering emphasizes ease of reading over ease of writing, and Ada, a language for SW engineering, explicitly adopts this attitude. "Verbose" is not a bad word among the SW engineers here. Changing the action in response to an event in the static version involves looking at the code for the event and changing the subprogram that is called. In the callback case, it involves finding code not obviously related to the code for the event and changing the subprogram that is registered. The flexibility seems similar; the ease of making the change seems greater in the static case. It's possible I've missed something since I haven't studied your C code in any detail. > 1. The solution to having no access-to-subprogram type in Ada83 is > usually passing the address of the function around and then in Ada a > function can be declared to 'use' that address as it's own like so: This is not something I would recommend, especially if it adds complexity to an otherwise simple problem. -- Jeff Carter "Now look, Col. Batguano, if that really is your name." Dr. Strangelove 31