Re: Link to zlib
Re: Link to zlib
- Subject: Re: Link to zlib
- From: "Sherm Pendley" <email@hidden>
- Date: Wed, 11 Jun 2008 14:06:21 -0400
On Wed, Jun 11, 2008 at 1:03 PM, Charles Srstka
<email@hidden> wrote:
> On Jun 11, 2008, at 11:40 AM, Sherm Pendley wrote:
>
>> Yes, in fact it does matter. If Xcode resolves the symlink and stores
>> a direct reference to libz1.dylib, then it will continue to use that
>> even if you later move to a newer SDK with a newer version of libz.
>> When ld resolves the symlink, it does so each time you build, so
>> you'll always get the correct version for the SDK you're using.
>
> The older versions are usually symbolic links to the newer ones anyway, so
> if an app links against libcurl.2.dylib or libcurl.3.dylib, they end up
> getting libcurl.4.dylib anyway.
So? My point was that how you specify the library in Xcode does make a
difference in how the app is linked. As you've pointed out, newer OS
releases are able to smooth over the difference, but that's not the
same as there being none.
>> My solution for that is simple. I don't want to write my code twice,
>> so if I want to support 10.3, I write it using methods that are
>> available on that version. And if I need to use methods that *aren't*
>> available on 10.3 - or an entirely new framework, such as Core Data -
>> I don't even try to support 10.3.
>
> There's a few reasons I don't do that:
>
> 1. The more users can run your app, the more potential customers you have.
>
> 2. The more users can run your app, the fewer e-mails you get asking "why
> can't I run this app?"
I fail to see the relevance of these points. Obviously, my goal is to
reach the maximum number of users; if it were otherwise I wouldn't be
discussing the means by which I reach them.
> 3. Relying on deprecated methods can cause an instant headache if Apple ever
> decides to remove those methods (or if they eventually start requiring you
> to compile for 64-bit or something).
If I had suggested using deprecated methods *forever*, you might have
a point. But I didn't suggest that. I only use deprecated methods if I
need to support an OS version for which they're not deprecated. That's
precisely the point of deprecation; it gives developers time to
transition away from the deprecated methods, instead of requiring us
to do so immediately.
In practice, I have yet to have had a problem with this - by the time
a deprecated method is actually removed, the OS version for which I
needed it has always fallen "off the radar" for other reasons (Cocoa
Bindings, Core Data, etc.) anyway. Obviously, there are no guarantees
of this, but in eight years of Mac OS X programming I've never been
bitten by an exception.
> 4. Sometimes a method gets deprecated because its replacement has better
> performance or has some other advantage that can make your app better if you
> use it.
If the advantage is significant, I simply bump up the OS version requirement.
> 5. Sometimes a new method allows me to add a cool new feature that wasn't
> possible on older OS versions without a lot of work, but this feature isn't
> so important that the app isn't useful without it. In this case, I can just
> implement the feature on the current OS, and it gracefully degrades on older
> OS versions (maybe a menu item is greyed out or something).
How is that a meaningful difference? If an OS feature is
mission-critical, the app will be useless regardless of how it
communicates the fact of its uselessness to the user. Besides, if my
app requires 10.4, I'll make that abundantly clear on its download
page. I don't think there's anything graceful about making someone
download an app and try to run it before telling them that they can't.
> 6. Often times a new method that shows up in a class can make your app
> better if you use it. What I often find is that Apple adds a method that
> does something I'd previously been using custom code in a subclass to do,
> but it does so in a manner that performs better or is more elegant in some
> way that is noticeable to the user. Or maybe it's just cleaner and my custom
> subclass code is kludgey or ugly. Either way, I would change my subclass
> method to do something like this:
>
> if(tiger or better) {
> return [super doTheOfficialThing];
> } else {
> // do my custom crap
>
> return whatever;
> }
If the benefit of the new method is significant enough to warrant it,
I simply use the new method and require the OS version that supports
it.
> Of course, this is for when an existing class gets some new methods that I
> like or something. I of course wouldn't use something huge like CoreData and
> then try to target 10.3, as that would just be silly.
Such huge additions are actually the reason I arrived at my position.
They tend to be the main drivers of my adoption of newer SDKs and OS
versions, to the point where I've simply stopped worrying about minor
additions and deprecated methods. By the time a deprecated method such
as -cString actually disappears, I will have long since switched to a
newer SDK for other reasons anyway, and updated my code to suit that
SDK.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
_______________________________________________
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