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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.