[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…
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.