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,eafb0c0f59b030c 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_s72.POSTED!53ab2750!not-for-mail From: "Jeffrey R. Carter" Organization: jrcarter at acm dot org User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Event mechanisms for GUI's References: <3egSg.208528$1i1.141541@attbi_s72> <1159338085.495558.286500@i42g2000cwa.googlegroups.com> <7s2dnaT_9fw5nobYnZ2dnUVZ_tOdnZ2d@megapath.net> In-Reply-To: <7s2dnaT_9fw5nobYnZ2dnUVZ_tOdnZ2d@megapath.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <_AHSg.210879$1i1.191702@attbi_s72> NNTP-Posting-Host: 12.201.97.213 X-Complaints-To: abuse@mchsi.com X-Trace: attbi_s72 1159415226 12.201.97.213 (Thu, 28 Sep 2006 03:47:06 GMT) NNTP-Posting-Date: Thu, 28 Sep 2006 03:47:06 GMT Date: Thu, 28 Sep 2006 03:47:06 GMT Xref: g2news2.google.com comp.lang.ada:6786 Date: 2006-09-28T03:47:06+00:00 List-Id: Randy Brukardt wrote: > > I would agree, but I certainly would disagree with your conclusions. That's OK. I'm aware that my views on such things as SW design and language design are not widely shared. Perhaps someone can show me that I'm wrong. That's one way to learn. > First of all, there is no simple or even satisfactory solution to this > problem. The trouble is that handling asynchronous events in a sequential > programming language (or even a high-level parallel one like Ada) is a poor > match. You complained about "a subprogram being called when a framework > pleases", but you have the same effect with any mechanism - the order of > operations depends on the events, not on the program. And any well-designed > framework will make it clear when subprograms will be called and by which > task. With configurable event queues, the user decides when events will be processed. With a callback mechanism, the framework makes those decisions. > Second, explicit event handling is among the worst solutions, because it > requires an explicit response to every possible event. A real GUI system > will have dozens, if not hundreds, of possible events for each Window. It's > easy to forget to handle some of those events; moreover any *explicit* code > necessary to do the *default* action reduces the readability of the system. > And the easiest solution (the others clause) completely eliminates the main > advantage of using case statements -- the completeness check. As I said, which events are and are not put on the queues should be configurable, and multiple queues should be able to be merged into one. An application which needs every possible event put on the queue will be quite rare. There will still need to be an others clause (for all those possible events that will not be put on the queue). It should raise an exception. If you forget to handle an event that you've specified should be put on the queue, that should alert you to the lack of completeness. > My final conclusion is that all of the solutions have severe trade-offs; > none is anywhere near optimal. My advice to the OP is to select a strategy > that works well for the problems that they want to solve, and not worry too > much about "goodness" -- it's not going to happen in a GUI (that's why GUI > builders are so indispensable). I've used callback, dispatching, and event-queue GUIs, and I prefer the latter. The code is much clearer. -- Jeff Carter "I like it when the support group complains that they have insufficient data on mean time to repair bugs in Ada software." Robert I. Eachus 91