Re: Implementing delegate categories for subclasses

On Sep 10, 2009, at 0:34, Kyle Sluder wrote:

> On Wed, Sep 9, 2009 at 3:01 PM, Christiaan  
> Hofman<[email protected]> wrote:
>> Why? There is still a huge overlap between 10.4 and 10.6, it's  
>> really not
>> such a stretch to build an app or support framework for all three  
>> major
>> versions. In particular for frameworks, and those typically should  
>> be as
>> versatile as possible.
>
> The proper way to do it is by either building on 10.6 against the 10.6
> SDK with a deployment target of 10.4, or building on 10.4 against the
> 10.4 SDK.  Otherwise you depend on the API never, ever changing.
> That's an unreasonable expectation.

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.

>
>> And quite frankly, I even still require some deprecated methods  
>> from 10.4
>> even on 10.6, because Apple simply did not give a proper  
>> replacement (due to
>> serious bugs and shortcomings in the API that replaced it).  But  
>> that's a
>> different story.
>
> You should, however, be able to depend on behavior not changing when
> you've built an app against a certain SDK.  Any case where that isn't
> true is a bug, and you should file a Radar.  That includes when
> methods are deprecated in the 10.5 SDK but you're building on 10.4 --
> a situation which has bitten us quite frequently.
>
> --Kyle Sluder

And here you give another reason to use an older SDK, because using a  
newer one may change the behavior.

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.

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.

Christiaan