This seems like a bit of code smell - next time when you plan to ask the user 
of your libraries override a method, put it into a delegate protocol. By doing 
this the end user does not need to actually subclass you and hence internal 
call structure no longer is part of the contract you have to keep all the time 
and internal refactoring like this can be done easier.

> On Sep 1, 2015, at 07:09, Graham Cox <[email protected]> wrote:
> 
> 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 protected])
> 
> 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/max%40maxchan.info
> 
> This email sent to [email protected]

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

Cocoa-dev mailing list ([email protected])

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 [email protected]

Reply via email to