> On 3 Sep 2015, at 1:34 am, Maxthon Chan <[email protected]> wrote: > > If this is your use case you can internally call the new method throughout, > and the new method discards the useless information and calls the old method > using the old contract. Updated programs will override the new method, > adopting the new behaviour, while contract of the old override point is still > respected and old program will still work. > > By the way mark your old method as deprecated, as it will generate a warning > and motivate the users of your library to adopt the new interface faster.
This is usually how I handle this sort of thing. However in this case there are a few additional kinks that made that approach awkward - I (over)simplified the use case. The real case is that the framework itself subclasses GCBase for a couple of concrete implementations, and client code then typically subclasses one of these concrete classes (though also sometimes will subclass GCBase itself). The framework’s own concrete classes need the extra parameter so override the new version of the method, but the client subclasses override the old method. So the updated internal subclasses either need to individually consider all the possible overrides and make sure they’re called, or the underlying base class can worry about it in one place and detect which one to call, which was what I was asking about. I guess it does make a difference whether this intermediate subclassing takes place or not, so sorry I oversimplified by leaving it out of the story. —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/archive%40mail-archive.com This email sent to [email protected]
