NSCaledarDate's deprecation

  • in anticipation of the deprecation of NSCaledarDate, i am in the
    process of converting my app to use NSDate and friends. and while the
    process is mostly straightforward and not all that difficult, it is
    tedious.

    when i think i'm done, i'd like to be able to do a fresh build and if
    possible have the compiler tell me any places i might have missed...
    these would be places where i used a method of NSCalendarDate that i
    missed with all my text searches.

    is there anyway to get the compiler to do this for me?

    thanx,
    ken
  • On 22 Jan 2009, at 22:52:56, <kvictor...> wrote:

    > in anticipation of the deprecation of NSCaledarDate, i am in the
    > process of converting my app to use NSDate and friends. and while
    > the process is mostly straightforward and not all that difficult, it
    > is tedious.
    >
    > when i think i'm done, i'd like to be able to do a fresh build and
    > if possible have the compiler tell me any places i might have
    > missed... these would be places where i used a method of
    > NSCalendarDate that i missed with all my text searches.
    >
    > is there anyway to get the compiler to do this for me?

    If you delete all occurrences of NSCalendarDate and what relevant code
    you can see, the compiler will pick up on undefined variables.
  • At Thu, 22 Jan 2009 23:13:45 +0000, Benjamin Dobson wrote:
    > On 22 Jan 2009, at 22:52:56, <kvictor...> wrote:
    >
    >> in anticipation of the deprecation of NSCaledarDate, i am in the
    >> process of converting my app to use NSDate and friends. and while
    >> the process is mostly straightforward and not all that difficult, it
    >> is tedious.
    >>
    >> when i think i'm done, i'd like to be able to do a fresh build and
    >> if possible have the compiler tell me any places i might have
    >> missed... these would be places where i used a method of
    >> NSCalendarDate that i missed with all my text searches.
    >>
    >> is there anyway to get the compiler to do this for me?
    >
    > If you delete all occurrences of NSCalendarDate and what relevant code
    > you can see, the compiler will pick up on undefined variables.

    i'm not concerned with "lagging" instances of the text
    "NSCalendarDate" as i'm pretty sure i can find and fix all of them. i
    am concerned with missing a call to a method of NSCalendarDate. if
    this were a class of my own, then i would simply remove the .h/.m
    files from my project and the compiler would then tell me of any
    erroneous calls. but i can't do that with cocoa files/classes. and
    since NSCalendarDate is a subclass of NSDate, using an NSCalendarDate
    method on an NSDate object is perfectly legal at compile time. and
    this is what i'd like to catch at compile time, especially if i have
    (erroneously) cast an NSDate object to id in the past.

    ken
  • > since NSCalendarDate is a subclass of NSDate, using an
    > NSCalendarDate method on an NSDate object is perfectly legal at
    > compile time

    This should raise a compiler warning.

    What you mean is that calling an NSDate method on an instance of
    NSCalendarDate is perfectly legal; however calling a method declared
    in a subclass, on an object strongly typed as it's superclass is not
    legal.

    Keith
  • On Jan 23, 2009, at 2:45 PM, <kvictor...> wrote:

    > At Thu, 22 Jan 2009 23:13:45 +0000, Benjamin Dobson wrote:
    >> On 22 Jan 2009, at 22:52:56, <kvictor...> wrote:
    >>
    >>> in anticipation of the deprecation of NSCaledarDate, i am in the
    >>> process of converting my app to use NSDate and friends. and while
    >>> the process is mostly straightforward and not all that difficult,
    >>> it  is tedious.
    >>>
    >>> when i think i'm done, i'd like to be able to do a fresh build and
    >>> if possible have the compiler tell me any places i might have
    >>> missed... these would be places where i used a method of
    >>> NSCalendarDate that i missed with all my text searches.
    >>>
    >>> is there anyway to get the compiler to do this for me?
    >>
    >> If you delete all occurrences of NSCalendarDate and what relevant
    >> code you can see, the compiler will pick up on undefined variables.
    >
    > i'm not concerned with "lagging" instances of the text
    > "NSCalendarDate" as i'm pretty sure i can find and fix all of them.
    > i am concerned with missing a call to a method of NSCalendarDate. if
    > this were a class of my own, then i would simply remove the .h/.m
    > files from my project and the compiler would then tell me of any
    > erroneous calls. but i can't do that with cocoa files/classes. and
    > since NSCalendarDate is a subclass of NSDate, using an
    > NSCalendarDate method on an NSDate object is perfectly legal at
    > compile time. and this is what i'd like to catch at compile time,
    > especially if i have (erroneously) cast an NSDate object to id in
    > the past.

    Once you cast to id all bets are off.  Maybe you could try a hack like
    temporarily removing NSCalendarDate.h, but even then there are other
    places where the compiler can't help you, like key paths and
    @selector().  I think if you want to be really, really sure you're
    going to have to grep your code for each of the 20 or so method names
    that are specific to NSCalendarDate and not NSDate.  Maybe you could
    write a script to do it.

    --Andy
  • At 6:39 PM -0500 1/23/09, Andy Lee wrote:
    > On Jan 23, 2009, at 2:45 PM, <kvictor...> wrote:
    >
    >> At Thu, 22 Jan 2009 23:13:45 +0000, Benjamin Dobson wrote:
    >>> On 22 Jan 2009, at 22:52:56, <kvictor...> wrote:
    >>>
    >>>> in anticipation of the deprecation of NSCaledarDate, i am in the
    >>>> process of converting my app to use NSDate and friends. and while
    >>>> the process is mostly straightforward and not all that difficult,
    >>>> it  is tedious.
    >>>>
    >>>> when i think i'm done, i'd like to be able to do a fresh build and
    >>>> if possible have the compiler tell me any places i might have
    >>>> missed... these would be places where i used a method of
    >>>> NSCalendarDate that i missed with all my text searches.
    >>>>
    >>>> is there anyway to get the compiler to do this for me?
    >>>
    >>> If you delete all occurrences of NSCalendarDate and what relevant
    >>> code you can see, the compiler will pick up on undefined variables.
    >>
    >> i'm not concerned with "lagging" instances of the text
    >> "NSCalendarDate" as i'm pretty sure i can find and fix all of them.
    >> i am concerned with missing a call to a method of NSCalendarDate.
    >> if this were a class of my own, then i would simply remove the
    >> .h/.m files from my project and the compiler would then tell me of
    >> any erroneous calls. but i can't do that with cocoa files/classes.
    >> and since NSCalendarDate is a subclass of NSDate, using an
    >> NSCalendarDate method on an NSDate object is perfectly legal at
    >> compile time. and this is what i'd like to catch at compile time,
    >> especially if i have (erroneously) cast an NSDate object to id in
    >> the past.
    >
    > Once you cast to id all bets are off.  Maybe you could try a hack
    > like temporarily removing NSCalendarDate.h, but even then there are
    > other places where the compiler can't help you, like key paths and
    > @selector().  I think if you want to be really, really sure you're
    > going to have to grep your code for each of the 20 or so method
    > names that are specific to NSCalendarDate and not NSDate.  Maybe you
    > could write a script to do it.
    >
    > --Andy

    thats what i suspected. thanx for the reply,
    ken
  • <kvictor...> (<kvictor...>) on 2009-01-22 5:52 PM said:

    > in anticipation of the deprecation of NSCaledarDate, i am in the
    > process of converting my app to use NSDate and friends. and while the
    > process is mostly straightforward and not all that difficult, it is
    > tedious.
    >
    > when i think i'm done, i'd like to be able to do a fresh build and if
    > possible have the compiler tell me any places i might have missed...
    > these would be places where i used a method of NSCalendarDate that i
    > missed with all my text searches.

    Take a look at the declaration of NSString.h's cString method.  Maybe
    you could hack NSCalendarDate.h and add DEPRECATED_ATTRIBUTE where desired.

    Sean
  • Please excuse this possibly dumb question but here it is:

    Why spend so much time and effort to remove some code that is going to
    keep running fine for years?

    The class isn't even deprecated yet. It's in this weird "going to be
    deprecated" limbo. How many years does it take between when something
    is deprecated and when it actually breaks? (not a rhetorical question)
  • 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/>
  • On Sat, Jan 24, 2009 at 4:14 PM, Nick Zitzmann <nick...> 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
previous month january 2009 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today