Overview

Haxle is a Signal and Slots Framework for haXe. Signal and slots frameworks are synchronous event handling systems. They work by 'linking' a given object method call (called a signal function) to another arbitrary (slot) object method. The second object method receives all the arguments from the first object, whenever and wherever it is called in the code.

Some benefits of signal/slots over conventional Event systems are:

• They need very little added syntax/boilerplate code
• They can control if slot functions happen before or after a signal function
• They can control the order in which slot functions are called
• They can modify arguments being passed between signal and slot functions
• They can set multiple signal declarations for the respective signal object function, and each signal in turn can be received by multiple slot objects.

The main negatives are:

• The haXe implementation must use strong references. If objects are connected with Haxle, then they must be disconnected before the slot object can be deleted completely.
• There is no type checking for the linked functions. It is up to the developer to make sure that the types match for the two linked functions.
• In this implementation, the signal call is a bit clunky. You must specify three parameters (the current object, the current object's function, and any arguments you want to forward on), and call it from the function you want to treat as a signal:

Haxle.signal(this, func1, array_of_args)

(Where this is the current object, func1 is the current method, array of args is the arguments passed to the method).

Unfortunately, due to runtime constraints on the different platforms, these parameters cannot be reliably extracted to use as defaults. They must be explicitly declared for each signal call.

Other Details

This class tries to impose a minimal burden on implementation, as well as maximum flexibility in signaling methods.

It works by adding an additional field (haxle_slots) at run time to any signaling class instance. The slot field is essentially a Hash of Lists (of method calls). This slot field contains a list of further object methods that should be triggered. To signal an event, a single static function call is made:

Haxle.signal(this, func1, arr_values)

(where this is the current object, func1 is the method, and arr_values are the arguments given to func1).

The Haxle class reads in the parameters in the arguments and looks up the method name entry in the haxle_slots field. If it exists, it will call each function it finds with the arguments from arr_values (an array of values).

Without a slot object method registered to the signal, nothing will happen. One must be specified explicitly using a static call. For example, say it's necessary to connect a signal function (func1) on an object (obj1) to another signal function (func2) on another object (obj2). First, you would insert a signal call from within func1 (as detailed above). Then you would connect these two functions together with:

Haxle.connect(obj1, 'func1', obj2, 'func2')

Somewhere in your main loop. Now, any functions called on obj1.func1() get passed on to obj2.func2()

If you want to disconnect them, then you can call:

Haxle.disconnect(obj1, 'func1', obj2, 'func2')

Check the http://haxle.googlecode.com/svn/trunk/src/Demo.hx file in the source tree for a very simple example.

Platform Specific Issues

Some platforms (Flash9+) do not automatically enable dynamic classes, and will throw errors at runtime if Haxle tries to access/create its haxle_slot field. To get around this, you can "implement dynamic" for your signaling class, which should enable class fields to be rewritten. Alternatively, you could also "implement HaxleStatic", and add the required slot field to your class definition explicitly.