On 01 Sep 2015, at 01:09, Graham Cox <graham....@bigpond.com> wrote: > Apple’s frameworks do this quite often, but I’m not sure how to achieve this > in my own. Something simple like -respondsToSelector: isn’t any good, because > of course it always does respond to the selector in the base class, and the > framework has no knowledge of subclasses beyond its own borders. Seems like > I’d need to drop down into the runtime functions but it’s still not really > obvious what would work. How do Apple do this?
Do subclasses call the superclass method, or not? If they don't (neither in their override, nor from outside), you could just remove the method in the base class, then implement -foo:withBar: to call -foo: if present? Alternately, you could offer a new base class. Anyone who wants to write against the new API, has to use the new base class. Existing code keeps linking against the old class, which still implements -foo:. You could then override -init to create an instance of the new class if the user just creates an instance of the old class without overriding anything. Or maybe you could walk the method list of a subclass instance and check if anyone below your base class implements -foo:, and if yes, swizzle in a compatibility implementation of -foo: or one of -foo:withBar: that calls -foo:? Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://stacksmith.org _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
