Re: A community Windows binding

[tmoran@acm.org]

>> 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.