Open mxcl opened 10 years ago
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.
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.
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.
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 aUIKit
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.