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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e429176c9adb07b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-20 14:06:36 PST Message-ID: <3E55501D.9050006@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?) References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E51A55A.3000101@cogeco.ca> <3E52A1BF.1020809@cogeco.ca> <3E53CE60.1030008@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Feb 2003 17:01:01 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045778463 198.96.47.195 (Thu, 20 Feb 2003 17:01:03 EST) NNTP-Posting-Date: Thu, 20 Feb 2003 17:01:03 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34312 Date: 2003-02-20T17:01:01-05:00 List-Id: Marin David Condic wrote: > I'd put the case statement part in the "Nice to have" category rather than > view it as the loss of some essential capability. Most of what you get there > is likely to be dealt with by dispatching & the rest is more of an > inconvenience than anything else. > > I'd agree that you don't want to totally rule out variant records.It is a > foolish design rule to say "Thou shalt not use feature X - ever." I'd simply > base the thing on tagged records and as the design evolved if circumstances > made it look like a variant might be a good answer, go ahead and create one. > My strategy would be tagged records, but I might use a tactic of a variant > occasionally. > > As for callbacks - I'd rather not see that at all. One or more message > queues would seem more elegant to me. Maybe that's just me, but callbacks > seem like some version of a computed goto - I've got to give you intimate > knowledge of the inside of my code (plus, structure my code according to > your whims) when I'd rather just have you send me data and let me figure out > what to do with it. > > MDC ... I don't think you can easily avoid callbacks. The problem with GUIs is that they tend to be dynamic. A popup is created (which has events), and then is gone, for example. A task with queue entries tends to be static in form. So if you end up with a task & queue model, you must somehow permit dynamic wiring in of events somehow, and it tends to be inconvenient in a static "form". I was thinking of the requirements of the OP query, about the isolation factor. Perhaps this has already been stated, but the task & entry idea is not a bad one if you use the callbacks do the rendezvous with the task. The callbacks handle the dynamic linkage between the GUI and the task (callbacks = glue or wiring). This is perhaps what you've been saying all along.. Then you simply specialize the queues accord to events and widgets as required. If properly done, you should be able to link with a X11/MOTIF, Windows, GtkAda or whatever library and maintain the same core. At least that is the theory. The one place where you might get foiled is the way that user data is handled by each GUI. To do this, I think you might need to use a preprocessor like gnatprep. Is this true? Hmmm.. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg