Why is setEntryDate method not deleted?


#1

On page 56 in the section “Initializers with Arguments”, in lottery.m, the newEntry init and setEntryDate methods are replaced by the initWithEntryDate method.

Why is the setEntryDate method not removed from the LotteryEntry class? Dates are not mutable, so it can never be reset, so… doesn’t initWithEntryDate make setEntryDate irrelevant? (Except that on the next page, Rex is using setEntryDate. Shouldn’t he be reading the header to see what methods are available? Tell Rex to get with the program and use initWithEntryDate!)

Must be an obvious answer, something I’m not seeing…

Thanks


#2

[quote=“chocolate365”]On page 56 in the section “Initializers with Arguments”, in lottery.m, the newEntry init and setEntryDate methods are replaced by the initWithEntryDate method.

Why is the setEntryDate method not removed from the LotteryEntry class? Dates are not mutable, so it can never be reset, so… doesn’t initWithEntryDate make setEntryDate irrelevant? (Except that on the next page, Rex is using setEntryDate. Shouldn’t he be reading the header to see what methods are available? Tell Rex to get with the program and use initWithEntryDate!)

Must be an obvious answer, something I’m not seeing…

Thanks[/quote]

Why do you think that “Dates are not mutable” ?


#3

“Cocoa Programming for Mac OS X” 3rd edition, p. 52

“Instances of NSCalendarDate are basically immutable. You can’t change the day or time of a calendar date once it is created, although you can change its format string and its time zone. Because it is basically immutable, many objects often share a single calendar date object.”


#4

[quote=“chocolate365”]“Cocoa Programming for Mac OS X” 3rd edition, p. 52

“Instances of NSCalendarDate are basically immutable. You can’t change the day or time of a calendar date once it is created, although you can change its format string and its time zone. Because it is basically immutable, many objects often share a single calendar date object.”[/quote]

Well you’re not really changing an NSCalendarDate-object with the setEntryDate-method…

Page 49: “setEntryDate: sets the pointer entryDate to a new value”, i.e. you’re pointing it to a new NSCalendarDate-object

So it still makes sense to keep it even after you added initWithEntryDate IMHO


#5

[quote=“chocolate365”]On page 56 in the section “Initializers with Arguments”, in lottery.m, the newEntry init and setEntryDate methods are replaced by the initWithEntryDate method.

Why is the setEntryDate method not removed from the LotteryEntry class? Dates are not mutable, so it can never be reset, so… doesn’t initWithEntryDate make setEntryDate irrelevant? (Except that on the next page, Rex is using setEntryDate. Shouldn’t he be reading the header to see what methods are available? Tell Rex to get with the program and use initWithEntryDate!)

Must be an obvious answer, something I’m not seeing…

Thanks[/quote]

Well Rex might get with the program, he might not. If he is with the program, as is well because the init method never gets called.

However, if Rex is NOT with the program and choses NOT to use the initWithEntryDate: method, several things happen:

1.) The init method gets called when Rex instantiates the bigWin object using alloc and init as on pg. 57
2.) The init method creates a date object by calling the class method calendarDate.

3.) The date object created is, as you pointed out, immutable.
4.) The init method then passes this created immutable date object to the initWithEntryDate: method, and thereby…
5.) pointing the entryDate pointer to the said immutable date object.
6.) Now, when Rex (who is ignorant of steps 2-5) now calls

  [code][bigWin setEntryDate: today][/code]
  resulting in re-pointing the entryDate pointer to "today", another date object (also immutable) which Rex conjured up all by himself a little earlier.  In doing so, Rex unknowingly ophaned the date object created by the [b]init[/b] method in Step 2.

Rex is blissfully unaware that he created and orphaned a date object in this scenario, however, the immutability of said date objects is not the issue. This issue is that Rex created and then orphaned a date object.

No worries though, since the class method calendarDate returns an autoreleased object, which means the orphaned date objects eventually gets released keeping the memory manager happy.