Question

I have a property:

@property(readwrite, ?????) NSDate *selectedDate;

The accessors are like so:

NSCalendar _calendar;
NSDateComponents _selectedDateComponents;

@dynamic selectedDate;
- (void)setSelectedDate:(NSDate *)newDate
{
    @synchronized(_selectedDateComponents)
    {
        if (!newDate) return;

        [_selectedDateComponents release];
        int requiredComponents = NSDayDateComponent | NSMonthDateComponent | NSYearDateComponents;
        _selectedDateComponents = [[_calendar components: requiredComponents fromDate:newDate] retain];
    }
}

- (NSDate *)selectedDate
{
    @synchronized(_selectedDateComponents)
    {
        if (!_selectedDateComponents) return nil;

        return [_calendar dateFromComponents:_selectedDateComponents];
    }
}

The class doesn’t keep a reference to the object that is sent to the setter. None of the retain, copy or assign seem appropriate. I like having this functionality encapsulated as a property but maybe a property is not appropriate.

What’s your view?

Answer 1

If you are writing your own setters, it doesn’t matter what you use. It only serves as a hint to how it works to yourself/other developers.

The property type only really affects the methods created by @synthesize. So if you provide your own methods, you dictate the retain strategy yourself, and the property strategy form the declaration is mostly ignored.

In this case I would use copy. Because, while you are not using a direct copy, you are storing value from that come from the passed in object and storing them in a non obtrusive way to that object. So you are copying the info out, just into a different format. But as far as the compiler cares, it doesn’t really matter at all. It’s purely for show when you write your own setter.