Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
- Subject: Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?
- From: Quincey Morris <email@hidden>
- Date: Tue, 06 Sep 2011 12:29:11 -0700
On Sep 6, 2011, at 11:47 , Jens Alfke wrote:
> I disagree. This is done all the time; for instance, as of June, Google Chrome/Chromium still builds using the 10.5 SDK, but has code to call new methods in 10.6 and 10.7. If your app is primarily written for the old OS but wants to add a few new behaviors for the new one, I think this is the right way to go. When moving to fully adopt the new OS, of course you should switch to using its SDK.
>
> Linking against the 10.6 libraries is the correct behavior if the app hasn’t been fully updated to use 10.7 features/behaviors. There are a lot of cases where a system framework will change its behavior based on which version the app linked against, as a backward-compatibility measure. For this reason, changing the SDK setting in Xcode can often set you up for a lot more work than you’d intended, as it can break your app until you update your code accordingly.
What I'm saying is that I don't recall there being any recognizance (being "done all the time" -- like adultery IRL -- notwithstanding) of the concept of an app being built against one version of the OS targeting a newer version. OTOH, it's very well understood that an app built against one version can target an earlier version -- there being, of course, build settings designed to represent this situation.
The case of "where a system framework will change its behavior based on which version the app linked against" was in fact my argument *against* the practice you're advocating. If you're starting to use (say) various new NSDocument features provided by 10.7, it seems to me that the last thing you want is for some (in effect) random subset of the API methods involved having their proper 10.7 behavior suppressed because Lion thinks your app is linked against 10.6.
That whole "where a system framework will change its behavior based on which version the app linked against" mechanism is, I think, looking at the way it's described at the top of the release notes, predicated on the idea that your adoption of 10.7 API methods *implies* you've revisited your application's behavior to ensure that it works properly with the 10.7 behavior changes, even where you didn't use new APIs.
Furthermore, I'd argue that pasting pieces of the 10.7 SDK headers into your own header files is fraught with peril, both legal and technical.
But I'm happy to allow that I'm being too absolutist on this, if this is in fact the situation. It just struck me that the OP's problem really resulted from failing to adopt the 10.7 SDK formally while still trying to adopt the 10.7 SDK haphazardly.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden