On Sat, Jan 24, 2009 at 4:14 PM, Nick Zitzmann <n...@chronosnet.com> wrote: > > On Jan 24, 2009, at 9:40 AM, Paul Bruneau wrote: > >> Why spend so much time and effort to remove some code that is going to >> keep running fine for years? > > > Because you don't know that. Stuff can change at any time and break your > application in unexpected ways in the future, though you do get advance > warning. Some people around here might remember the chaos that ensued when > Apple shipped Mac OS 7.0 18 years ago. Mac OS 7 introduced real 32-bit > addressing, which completely blew away every app that assumed that the top 8 > bits of a pointer were unused by the OS (in Mac OS 6 and earlier, the OS > used 4-byte pointers, but the top byte wasn't doled out by the OS).
Bad analogy. That top byte was always marked as reserved. Applications that noticed it was unused and used it were violating Apple's API contract. Apple has, as far as I know, never actually removed or disabled a Mac OS X API without also crossing a binary compatibility boundary. (E.g. they removed the GUI bits of Carbon, but only if you cross into 64-bit land.) NSCalendarDate isn't even deprecated yet. Apple is not going to remove it in any way that would break currently shipping code. They *may* remove it the next time they cross a binary compatibility boundary, but that would only happen after they *officially* deprecate it (instead of this "will be deprecated" weasel word nonsense) and then your currently shipping code will still be unaffected; only if you try to make your code cross that boundary will you encounter problems. In conclusion, rewriting a bunch of code that uses a class that isn't even deprecated yet, just discouraged, is pointless unless you get some other benefit from doing so. With NSCalendarDate, that other benefit is being able to use non-Gregorian calendars. If that helps you, great, if you're married to Gregorian for reasons other than using NSCalendarDate then there's absolutely no reason to switch now. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
