Added support for OS X

2.4.0

merged README

Bug fix for methods called from within dealloc

Any method called from within dealloc would previously cause a crash if that method was extended with @implementation_combine or @implementation_safe

For example, with the following class:

@implementation MyClass

- (void)dealloc
{
  [self doSomething];
}

- (void)doSomething
{
  // do something here
}

@end

If the -doSomething method was extended as follows:

@implementation_combine(MyClass, Additions)

- (void)doSomething
{
  dzlSuper(doSomething);
  // do something else here
}

@end

This would have caused a crash prior to this release. This issue is now resolved and requires no code changes to take effect.

Bug Fix

Fixed a bug that meant a method could not be combined with more than one class’s implementation of that method within a class hierarchy.

For example, in the following class hierarchy:

UIViewController
-> BaseViewController
-> MyViewController

It would cause an infinite loop if -viewDidLoad was "combined" on both MyViewController and BaseViewController.

This is now resolved and requires no code changes to take advantage of this fix.

Support combine with non-existent method

1. When using @implementation_combine, if a "combined" method isn't implemented on the underlying class, an exception is raised on app launch (from an assertion).

In order to remove this assertion from an implementation, pass the third argument dzl_no_assert to the @implementation_combine macro, as follows:

@implementation_combine(MyViewController, Additions, dzl_no_assert)

- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
  dzlSuper(scrollViewDidScroll:scrollView);
}

@end

The extra parameter is optional and therefore doesn't change the normal syntax of @implementation_combine, which remains as follows:

@implementation_combine(MyViewController, Additions)
@end

The main benefit of this is that protocol methods don't need to be implemented by the underlying class (e.g. delegate methods).

2. New macro dzlCombine has exactly the same syntax as dzlSuper but doesn't require the underlying class or its superclasses to implement the method.

3. When using dzl_no_assert you may wish to check if the underlying class implements the method. To do this, call dzlCanCombine(), which returns YES if the underlying class implements the method.

Calling dzlCombine will not cause any problems if the underlying class does not implement the method, so using dzlCanCombine() is not always necessary. But it can help if the underlying method is expected to return a particular value.

Improved Reliability + Removed Dependency on Obj-C Runtime

1. Improved the way in which underlying methods and super methods are invoked from "combine" and "safe" categories. The improvement gives meaning to the parameters by requiring them to be prefixed with their name and a colon in the same way any other Objective-C method is called

When implementing a combination method - (void)hitTest:(CGPoint)point withEvent:(UIEvent *)event;, you would previously have invoked the underlying method as follows:

combineOriginal(point, event);

This would now be invoked as follows:

dzlSuper(hitTest:point withEvent:event);

2. Another change allows self to be used as expected within methods that have been implemented in these kinds of categories.

3. A compiler warning will now be raised if dzlSuper is not called from a method in which it has been demanded by NS_REQUIRES_SUPER.

4. You must not call super directly. It will result in an infinite loop due to the implementation. Always use dzlSuper as described above.

5. @implementation_combine now asserts that each method implemented exists in the underlying class hierarchy. This is intended to help with renaming methods in the underlying class. It doesn't make sense to want to "combine" a method implementation if that method doesn't exist. If that is the aim, use @implementation_safe instead.

Initial Release

1.0.0