Event Driven Architecture Programming in Lisp Part 2

References for our discussion:

• The power of abstraction, reuse and simplicity: an object-oriented library for event-driven design. Most of the code implemented for a EDA is derived from this document.
  
• Graphic Objects. Lisp example for EDA. Specifically Graphic User Interfaces.
• Big, Complex, and Tested? Just Say ‘When’. Ruby example. Follows closely Bertrand Meyer’s document for the implementation of the

Requirements for our EDA:

• Storage of events to be executed when events triggered.
• Events.
• Push/Pull Model.
• Broadcast of events. One trigger can execute more than one handler.
  • Ex. When User Clicks Save Button, data is saved and the event is logged as executed.

Event Driven Architecture Programming in Lisp Part 1

• What is Event Driven Architecture Programming?
  • It is the ability to inform interested objects (consumer/subscriber/sink) of changes of state from other objects (producer/subscriber/source) with events.
• Why use this architecture?
  • There are two reason to use this architecture. One is to loosely couple the interacting objects. The second is that it is best-suited for use in an asynchronous context.
• What are the components required?
  • A table that stores event-handlers
  • An interface to register a trigger of events.
  • An interface to register notification of an event trigger.
  • An interface to trigger events.
• How to represent events?
  • Closures

An Object in Lisp. Part 4

• What does it mean to be an object?

• A [computer] language mechanism for binding data with methods that operate on that data. Object (Computer Science).

  • Binding is the creation of a simple reference to something that is larger and more complicated and used frequently. Binding (Computer Science).

  • Data refers to a collection of facts usually collected as the result of [...] processes within a computer system [...]. Data.

  • [...] a method usually consists of a sequence of statements to perform an action, a set of input parameters to customize those actions, and possibly an output value (called return value) of some kind. Methods (Computer Science).

So the following code by the above definitions must be an object.

(defun make-counter-obj ()
  (let ((counter 0))
    (list :increment-counter
          (lambda ()
            (incf counter))
          :get-counter
          (lambda ()
            counter))))

(defun increment-counter (obj)
  (funcall (getf obj :increment-counter)))

(defun get-counter (obj)
  (funcall (getf obj :get-counter))

• ‘make-counter-obj’ creates the binding.
• The ‘counter variable in ‘make-counter-obj’ is the storage for our data.
• The two functions/methods ‘increment-counter’ and ‘get-counter’ are definitely methods of some kind, that allow us to operate on the ‘counter data.

Throughout this entire series it seemed to be inevitable that p-lists were to be used not only the actual storage mechanisms for the methods that act on the data, but also in the macros, p-lists are a major data structure.

Right now, I’m pretty comfortable with the implementation of this type of object. But already I can see future implementations. There is definitely another abstraction that can be pulled out of this. The ‘get-object-id’ function is a place to start. All object instances, that use my objects language, use this function. It could be considered part of a parent property.

Right now I want to start integrating Event Driven Architecture to further my cargo-cultism of Lisp.

• The power of abstraction, reuse and simplicity: an object-oriented library for event-driven design.
• Graphic Objects.

Have a Happy Holiday,

Joe G