cmarti1138 February 2016

self.property = self.property in objective c

Good morning, I am looking through some old code online in objective c and I am having trouble finding out what the following means.

The class is subclassing UIView and is following the UIScrollViewDelegate protocol. The following is the class method I have some questions about:

@property(nonatomic, strong) NSDate * _Nonnull date;

- (void)layoutSubviews {
    [super layoutSubviews];

    if(!self.pagingView) {
        UIScrollView *pagingView = [[UIScrollView alloc] initWithFrame:self.bounds];
        pagingView.pagingEnabled = YES;
        pagingView.directionalLockEnabled = YES;
        pagingView.delegate = self;
        [pagingView setAutoresizingMask:UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight];
        [self addSubview:pagingView];
        self.pagingView = pagingView;
    }

    CGRect f = self.pagingView.bounds;
    CGSize s = self.pagingView.contentSize;
    if(s.width != f.size.width * 3) {
        self.date = self.date;
        }
}

First, I am not sure what the [super layoutSubviews] is achiving and I am not sure what the self.date = self.date is trying to do. Is it only setting itself with itself? If so, I am not able to get this to work with swift. (Which I am trying to convert the code to)

https://github.com/Daij-Djan/DDCalendarView/blob/master/DDCalendarView_objc/DDCalendarView.m

Thanks again for any help;

Answers


Andrew Madsen February 2016

In Objective-C, dot notation is a shorthand (syntactic sugar) for property accessor method calls. What you've posted could be rewritten as:

if width != size.width * 3 {
    [self setDate:[self date]];
}

In other words, the current value of the date property is being passed back into the date property setter. In typical code, this won't really do anything. Without seeing the implementation of the date setter (and/or getter) method, it's impossible to say why the code you're looking at is doing this. However, my guess is that the date setter has a side-effect that is triggered anytime it's called, so this is a convenient way to trigger that side-effect without changing the property's value.

Assuming this is the case, I would add that this is not very good code. At the very least, there should be a comment explaining what this is doing. Even better would be to break whatever side-effect is happening out into its own method, so that it can be called explicitly instead of relying on the date setter even in cases where the property value shouldn't be changed.


Gavin February 2016

Looking at the code you posted, the setDate: method is performing some view setup, so doing self.date = self.date; is the author's way of forcing this setup to be done without changing the set date. This would be better done if that view setup code was factored out of setDate:, so that it would simply make a call to do that setup after a new date is set. Then in your above code, it could simply call that setup method, something like updateDateViews or something along those lines.

As for your question about the code calling [super layoutSubviews];, it is always a good idea any time you override a method to call the superclass implementation, unless you know for sure what the superclass implementation does and you know that you don't need to call it, and in rare cases specifically don't want to call it. So a good rule of thumb is to just always add the call to the superclass method. It's the same as when you override viewWillAppear:, viewWillDisappear:, etc. You should always be calling the superclass implementation for those.

Post Status

Asked in February 2016
Viewed 2,118 times
Voted 7
Answered 2 times

Search




Leave an answer