PackageDescription: Attractions


Last published: July 8, 2007 by 'michael'

Defines 6 Classes
Extends 7 Classes

A simple event system with attraction and repulsion at its core. You can attract: an event or repel: an event and you can emit: an event to be attracted or repelled.

Subclasses of Attractions.Attractor can emit events that you may be attracted to. You can use events for UI or Domain models.

fileDownloader attract: #completed to: self do: [:event | Transcript cr; show: 'Download complete!'].
fileDownloader emit: #completed do: [Attractions.Event new].
fileDownloader repel: #completed from: self.

Sending #release will repel all currently attracted events.

Events are broken up in to three aspects: Who, What, Why. The Who is the receiver, as it is with most event systems. The What and Why are often opposites in event systems. For example, Announcements gives you What (ModelChanged), but not Why. Trigger-Events gives you Why (#changed) but not What.

Attractions give you all three, Who, What Why. For example, in the line:
fileDownloader attract: #completed to: self do: ...
We are saying we're interested in the Who: fileDownloader and the why: #completed. Then when we emit: the What comes from Attractions.Event new.

Because we're in a dynamic language, we can accept polymorphic objects being given to us inside the block for our attraction. We assume that because the Who and Why are understood that the What will be something we can understand too. As such, it is easy for other objects to change the What when they emit the Why.

And example of this would be mouse inputs. We can listen to an event that is #mouseMoved and the What may be MouseMovedEvent or perhaps it is TranslatedMouseEvent - why don't care so long as both objects give us back #point as the polymorphic api.

By reifying the Why in to a Symbol we can have a very wide ontology of events. By reifying the What in to a Class, we can avoid anonymous parameters and have real protocols with real instance variables. This approach avoids the two obvious flaws with Trigger-Events (no real APIs on event objects) and Announcements (class hierarchy explosion).

As a bonus, the Attractions-UI package replaces the low level change/update UI event system to use the same Attractions API. Gizmo makes use of this package.

The Attractions event system does not advocate either a Slot based or Domain based event system. You can just as easily create a ValueModel type system with Attractions as to not.