[Tutor] When to use classes

[Steven D'Aprano]

On Sat, Aug 19, 2017 at 11:34:10AM -0600, Mats Wichmann wrote:

> It makes some sense though; computational code just goes ahead and
> computes.  In the graphical UI world, interesting things happen when an
> event you can't exactly plan for takes place.  From the point of view of
> a computer program, waiting for somebody to move a mouse and click it is
> a slow, infrequent, and unpredictable event, so you set up callbacks
> which are invoked when one of those events happens, and in the meantime
> you can either do other productive work, or do nothing at all (let other
> programs on the computer do work).  I'm finding it hard to imagine
> tkinter without them...

I've never got into GUI programming because I was so thoroughly spoiled 
by one of the first programming languages that I learned that everything 
since then feels like going back to the Dark Ages. Having to care about 
low-level details like creating buttons, installing callbacks and so 
forth just feels wrong.

There is an alternative to callback based GUI frameworks, and that is an 
message-passing, event-driven language. The framework handles the events 
for you, and fires off messages to objects. If the object doesn't handle 
the event, it is sent to the next object in the message-passing 
heirarchy.

The language was Hypertalk, the scripting language of Apple's Hypercard 
application in the mid to late eighties.

Hypercard was seen by Apple as a kind of Rolodex application, with a 
"card" metaphor, and programmable objects (text fields and buttons) that 
you can copy and paste between files. Apple invisiged that developers 
would program the objects and users would simply copy and paste them, 
and to their utter surprise they were overwhelmed by the number of end 
users who started programming their own objects.

By today's standards it is woefully primitive: only a single window, of 
a fixed size, black and white graphics, and only a fixed set of 
pre-defined GUI widgets and no way to create your own. But it is 
remarkable just how much power there is in just two widgets, text fields 
and buttons, especially since the buttons can be specialised into push 
buttons, radio buttons and checkbox buttons.

But I digress... the Hypercard model was that of a stack of cards. Each 
stack (Hypercard document) consisted of at least one shared background 
used by at least one card. Cards inherited their look, state and 
behaviour from their background, but could override any part of that.

You used the integrated GUI designer to lay out your shared objects in 
the background, and customised objects on the card.

The Hypercard application managed the GUI event loop for you. It tracked 
the mouse and the keyboard, and other events, and each time it noticed 
an event, it sent a message to the appropriate object (a widget, card, 
background or stack). That object could either handle the message, or 
ignore it. If it ignored the message, it passed on to the next object in 
the heirachy.

To program your "stack", you create message handlers that respond to 
events. E.g.:

on mouseUp
  # sent when the mouse button is released over the object

on idle
  # sent when nothing else is happening

on opencard
  # sent when we've just navigated to another card

on closecard
  # sent when we've just navigated away from the current card


If this looks a tiny bit like Javascript, that's because Javascript 
borrowed the idea and language of handlers from Hypertalk and 
Hypercard.

To call a handler in another object, you sent your own message, and the 
Hypercard application would manage the details:

send "print" to field "Address" of card "George"

That message would be sent via the same message path as any other event, 
so if the field itself couldn't handle it, it would next go to the card 
"George", then the card's background, then the current stack, and 
finally Hypercard itself, which would complain that it didn't know 
anything about "print" events. (Events it did know about, like idle or 
mouseDown or closeCard, would just be silently ignored.)


-- 
Steve