TyphoonAssembly

"Any magic, sufficiently analyzed is indistinguishable from technology."

Clarke C. Arthur

Here will take a look at how Typhoon assemblies are instrumented at run-time to allow the following feature:

• Before Activating-Assemblies your assemblies return an instance of TyphoonDefinition
• After activation an instance built according to the rules in the definition is returned.

#Assembly Instrumentation

Typhoon uses a programming paradigm called Aspect Oriented Programming (AOP) to instrument the methods of your assembly classes with additional behavior.

AOP is used to encapsulate "cross-cutting" concerns. These are the kind of requirements that "cut across" many modules in your system. In our case the requirement is:

Whenever a new definition is created it should be assigned
a unique key based on the method name that defined it. 

AOP defines the following kinds of method interceptions:

Interception	Description
Before	Additional behavior is added before a method invocation.
After	Additional behavior is added after a method invocation.
After Throwing	Additional behavior is added after an exception occurs.
Around	A flexible style that can be used to model any of the above.

TyphoonAssembly instrumentation uses the 'After' style - after a definition is returned it as allocated a unique key based on the method name that defined it.

##Registration into TyphoonComponentFactory

• After instrumentation each of the definitions in your assemblies - we can think of these as blue-prints for creating a an instance - are registered into a TyphoonComponentFactory
• The TyphoonComponentFactory then runs its' TyphoonDefinitionPostProcessor system to modify these recipes for creating an instance. Post processors can be plugged in to perform things like configuration.

#How is method interception achieved?

Method interception is achieved using the Objective-C run-time. Objective-C is a 'late binding' language or in other words it uses messaging or dynamic dispatch to achieve method invocation. This affords the ability to forward method invocations to an alternative implementation, optionally calling the original. This is known as swizzling.

The following kinds of Swizzling are provided:

Swizzle	Effect
Method swizzling	Forward invocations of a method for all instances of a given class, optionally calling the original.
isa pointer swizzling	Forward invocations of a method for a specific instance of a given class, optionally calling the original.

NB: Other languages that use static dispatch can achieve 'late binding' by virtue of having a 'class loader' system, which provides an alternative hook point.

##A hack? Not at all

Swizzling has sometimes been described in informal discussion groups as a hack. Like any powerful technique it can be easily misused, however it can be used for more than Aspect Oriented Programming, in fact it is the foundation of many of Cocoa's most powerful features, including:

• Property Observers (KVO) : Property setter is intercepted to notify subscribers when a new value is supplied.
• Core Data Managed Objects
• etc

#A Cat, All Dressed Up as a Duck

At runtime an instance of TyphoonComponentFactory actually poses as your assembly class.

• When an Objective-C method is invoked for a given instance, a look-up table is consulted to resolve that method to a function pointer.
• When a method that does not exist for that class is invoked, before raising an error, the object is given the opportunity to forward the invocation to an alternative endpoint.

Invocations of TyphoonComponentFactory methods are redirected to the method

-(id) componentForKey:(NSString*)key

. . using the unique key that was generated when instrumenting the assembly above.

(add diagram?)

#Benefits

We use a meta programming DSL to define dependency injection container with rules for assembling instances.

• No magic strings - use regular IDE refactoring tools for code-completion, method renaming, etc.
• Allows collaborating assemblies / modularization
• Allow more than one component of the same type by supporting explicit wiring as well as auto-wiring. (Objective-C is weak on auto-wiring in any case - type information is only returned for properties).
• Does not require any IDE plugins or special tool support.