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,4b27f494a96e0530 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!wns13feed!worldnet.att.net!attbi_s52.POSTED!53ab2750!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: A community Windows binding References: <9JI9d.213784$D%.188112@attbi_s51> X-Newsreader: Tom's custom newsreader Message-ID: NNTP-Posting-Host: 24.6.132.82 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s52 1097303021 24.6.132.82 (Sat, 09 Oct 2004 06:23:41 GMT) NNTP-Posting-Date: Sat, 09 Oct 2004 06:23:41 GMT Organization: Comcast Online Date: Sat, 09 Oct 2004 06:23:41 GMT Xref: g2news1.google.com comp.lang.ada:4949 Date: 2004-10-09T06:23:41+00:00 List-Id: >> system. You have to write little pieces of code that can be invoked in >> any order at any time outside your control. You have to use global >> variables extensively for these little pieces of code to communicate. >For example: in windows a reference to an object may be associated with >a window. The message handling routine has access to the window, and >likewise the reference to the object. Nothing is global. In Windows *all* events are associated with a window (whether it makes sense or not). In a system using dispatching like Claw, you declare, eg, type This_Window_Type is new Basic_Window_Type with record ... and the window of This_Window_Type is passed to the dispatched routine, which has access to the contents of the record extension. Nothing need be global. >> The code is difficult to read because you have to understand all these >> little pieces to understand any part of the software. It does force you to think in an OO way: you must think about the type This_Window_Type ... and its behavior independent of anything else. What should a This_Window_Type do when the user asks to resize it? What should it do when there's a redraw request (perhaps some data has been changed and the redraw should show the updated data). What should happen when the mouse is moved or clicked in the window? Ideally, you will be creating (or using) a new reusable object. For instance, in Orbitals (www.adapower.com/os/orbitals.html) there's a reusable window that displays in 3-D a set of points, rotated by mouse movement. The rest of the program, or any program using type Cloud_Display_Type(Max_Particle_Count: Positive) is new Claw.Basic_Window.Basic_Window_Type with private; need know nothing about displaying or stereo projection or tracking mouse movements or resizing windows. The total required external interface of the type is open, close, and set data values. Yes, at a higher level of abstraction you need to think simultaneously about calculating the point data and about displaying it, but you can focus on each of those quite separately. >> With an event queue approach, one writes standard imperative software >> using your standard imperative language (Ada's about the only one). The >> code is well structured and easy to read and understand. A windows interface is user-driven: the user can click or key in any order at any time outside your control. So the event queue approach turns out to be loop case Fetch_Next_Event is when resize => ... when keyin => ... when draw => ... A dispatching system like Claw simply makes that internal and each "when" branch consists of a dispatching call to, eg, When_Resize, for that Type of window. Given the number of different events ("case" branches) and the possible different kinds of windows (implemented by "if" or subsidiary "case" statements in each branch), explicitly writing the event queue code for any non-trivial program would be truly huge and ugly.