• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSCaledarDate's deprecation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSCaledarDate's deprecation


  • Subject: Re: NSCaledarDate's deprecation
  • From: "email@hidden" <email@hidden>
  • Date: Fri, 23 Jan 2009 15:47:45 -0800

At 6:39 PM -0500 1/23/09, Andy Lee wrote:
On Jan 23, 2009, at 2:45 PM, email@hidden wrote:

At Thu, 22 Jan 2009 23:13:45 +0000, Benjamin Dobson wrote:
On 22 Jan 2009, at 22:52:56, email@hidden 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 _______________________________________________

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


  • Follow-Ups:
    • Re: NSCaledarDate's deprecation
      • From: Paul Bruneau <email@hidden>
References: 
 >Re: NSCaledarDate's deprecation (From: "email@hidden" <email@hidden>)
 >Re: NSCaledarDate's deprecation (From: Andy Lee <email@hidden>)

  • Prev by Date: Custom view and ViewController
  • Next by Date: ibplugin - framework - application
  • Previous by thread: Re: NSCaledarDate's deprecation
  • Next by thread: Re: NSCaledarDate's deprecation
  • Index(es):
    • Date
    • Thread