Re: NSCaledarDate's deprecation
Re: NSCaledarDate's deprecation
- Subject: Re: NSCaledarDate's deprecation
- From: Nick Zitzmann <email@hidden>
- Date: Sat, 24 Jan 2009 14:14:48 -0700
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). I think it also broke the "feature" where a
program could copy a pointer out of the jump table and execute that
instead of using interrupt time, which was a common optimization trick
in older versions of the OS.
I already had to go into a third-party class that made the false
assumption that void * would always be a 4-byte value, and rewrite a
good deal of it so it no longer made that assumption, because while it
may keep running fine for years on X86 and PPC, it won't run at all on
X86-64 or PPC64, and guess which architecture is going to be the
future of Mac OS X? That was not fun, and could have been avoided had
the developer thought ahead.
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
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