CALayer rather than NSObject

[mxcl]

Just a thought. Feels wrong to me to put the animate method on NSObject. It's not that low level.

But IMO having animate on UIView was a wrong decision by Apple also. I'd probably have had a UIKit container-style empty class.

Or done a c-function, like dispatch_async() is c-functions.

Anyway, maybe they should be on a MCAnimate class?

Feel free to close without comment if this rubs you the wrong way.

[matthewcheok]

Although I would agree that animation shouldn't really be as low level as NSObject, Pop could technically act on any object or property as long as a custom POPAntimatableProperty instance is configured and provided. That's why I thought it was okay to place the method on something as generic as NSObject while adhering to UIKit convention as much as possible.

Using a c-function would require prefixes which imo is overly verbose, but might be the next best alternative. I'm not terribly inclined to change this at the moment but I'm open to further discussion.

[mxcl]

Maybe

[POP animate:^{
    //…
}];

Really prefixing a c-function is no different from prefixing a class in terms of verbosity. But it probably would be weird to use a c-function for this. Not very typical.

[nunofgs]

For what it's worth, I'm having issues with the NSObject MCStopProxy category, which declares the method.

- (instancetype)stop;

This is causing a conflict between a project-specific audio-related class which also declares a -(void)stop method.

For now my solution is to avoid the shorthand syntax but it does seem to me that the category on NSObject is a bit too broad.