Re: Implementing delegate categories for subclasses
Kyle Sluder <[email protected]>
| Newsgroups | gmane.comp.macosx.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Sep 9, 2009 at 4:09 PM, Christiaan Hofman<[email protected]> wrote: > But doing so may change behavior (see your own remark below), and moreover > leads to a lot of warnings due to use of methods that were deprecated on > 10.6. It shouldn't lead to a change of behavior -- that would be a regression and a bug. It unfortunately does happen and you need to work around it. As far as the deprecation warnings are concerned, that's Apple telling you to update your source code. Quite frankly I wish they'd deprecate more on a more frequent basis; the most common reason for Snow Leopard incompatibility by far is dependence on deprecated API. > And here you give another reason to use an older SDK, because using a newer > one may change the behavior. Like I said, if that happens, file a bug and write a workaround. > Apart from that, this problem is not about change of behavior, but rather > functionality that is not (properly) supported by new API. Several bugs were > already long filed for 10.5, and they still exist in 10.6. Quite often this is intentional. Apple may want to privatize the behavior of some framework so they can change it at whim. > Moreover, I sometimes want to build with a different SDK for debugging > purposes (good to find deprecated methods or methods that were not supported > on older OSs). In particular Xcode 3.2 makes that very easy. Building with a different SDK will usually not produce useful debugging information. You're only going to compile with one SDK in the end, that's the one whose deprecation warnings etc. you should be concerned about. --Kyle Sluder