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-18 10:08:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? Date: Tue, 18 Feb 2003 12:10:31 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E51A55A.3000101@cogeco.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:34206 Date: 2003-02-18T12:10:31-06:00 List-Id: Warren W. Gay VE3WWG wrote in message <3E51A55A.3000101@cogeco.ca>... >Randy Brukardt wrote: >> Warren W. Gay VE3WWG wrote in message <3E5121BD.4010200@cogeco.ca>... >> >>>For input and output callback arguments, I use a discriminated record, >>>which then allows Ada95 checks on record members according to the event >>>type (ie. the record variation). This is something I wish GtkAda would >>>use. >> >> That doesn't work well if you have callbacks which are evolving (as most >> real-world GUIs are). Adding a new variant to a record can break >> existing code (think aggregates, think name conflicts), and will require >> recompiling everything in sight. > >I don't find this a particularly good argument. I want the code to break >if I change the callback requirements, even if just for one event. >Any structure changes are all localized to the variant >record, so it is very easy to locate conflicts (or simply let the compiler >do it for you). Of course not all variant record violations can be >detected at runtime (some can however). > >As far as "recompiling everything in sight", I feel this is not a good >reason to avoid it. If a recompile is necessary (which GNAT _can_ determine), >then let it compile away. This is an automatic process. > >Reluctance to recompile suggests that your goals are not in sync >with the end user's-- ;-) Most end users that I'm familar with don't want to have to rewrite all of their programs because we've provided an updated version of the interface with a few new features. That requires the interface to change as little as possible. Even adding a parameter can cause problems with extensions of a type. Adding visible components (which breaks all aggregates) is simply not acceptable. >The end goal, IMHO, is to produce a library that provides the best interface >to the user; not to be convenient to the library developer ;-) There is nothing "convenient to the library developer" about either of these "solutions". The best solution is to not have the problem in the first place. Thus, we use dedicated action routines (callbacks) whenever possible. The only place that we use any sort of variable data is in the lower-level Notification interface, and that's because Microsoft gives us no choice. Note that the notification interface in Windows is defined as a set of overlayed records, using which ever one is appropriate for the current message. There is no "variant" and certainly no discriminant. And each new thing Microsoft adds creates a bunch more of these. The big problem with the variant interface is that everything has to be defined in one place. That's usually not practical. The notification data includes various data types specific to each of the types of controls. If we had to put all of that in the spec. of the Claw root package, we'd more than double its size (and its already 5000 lines). We recently completed a project eliminating as much unused stuff from user programs as possible. If we had used a variant solution, there would be no possibility of that, as every possible control would have to be reflected in that variant. Since we used a tagged type, we don't have to drag in Tree Views unless the user actually withs Claw.Tree_View. (That was happening for another reason, and the internal restructuring eliminated that.) That cut the average size of Claw programs by 500K. >The X11 software (a real world GUI, BTW) uses a finite number of members >in the XEvent union (albiet in C, and certainly inferior to any Ada95 >variant record). This model has been well proven and works well. The >bonus is, that if you insist on a very general structure, this too can >be accomodated in a variant record with a system.address or some such >kludge. But at least that kludge is optional, and perhaps temporary as >your GUI evolves to perfection. If you're mapping an existing union, you're way ahead of the game. But that's a pretty limited GUI (and calling X11 a GUI is a stretch). Windows doesn't work this way, and I doubt that many of the higher level GUIs built on top of X11 do, either. Randy.