Mantaining legacy APIs in a framework
Mantaining legacy APIs in a framework
- Subject: Mantaining legacy APIs in a framework
- From: Graham Cox <email@hidden>
- Date: Tue, 01 Sep 2015 09:09:41 +1000
Hi all, a fairly general question.
Suppose I have a framework class - e.g. GCBase - that has a public method -foo: Application code that links to the framework can freely subclass GCBase and commonly overrides -foo:
Later, I decide that the method would be much better in a different form, let’s call it -foo:withBar: Code that links to the framework now should override this method instead. However, the framework can’t force this change on its clients, for a while it will need to support the older method -foo: if it has been overridden by a subclass. So the framework needs to arrange that if -foo:withBar: wasn’t overridden, but -foo: was, it should invoke the older override for backward compatibility until the client code is revised.
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?
—Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden