If you took advantage of properties you could do self.blueView = nil; and have the release be done for you.

I believe he IS taking advantage of an auto-retained property, which is why he needs the release... because the property setter has issued its own retain, which will be released when the property is set again...

With synthesized ivars, you must do:

  self.blueView = [[BlueView alloc] init];
  [self.blueView release];

When you allocate to get the proper retain count; I can demonstrate why by using a temporary variable:

  BlueView* bv = [[BlueView alloc] init]; 
   //Retaincount = 1
  self.blueView = bv;
   //Reaincount = 2
  [self.blueView release];
   //retainCount = 1

And then in dealloc

  [self.blueView release];
   //retainCount =0;
  

So in dealloc I could call your function, but there are things in various object packing schemes (KVO most importantly) where calling the setter like that screws stuff up. It's better to just call the getter (which should be side effect free) and release the returned object.

So looking at retain counts in the original example:

  self.blueView = [[BlueView alloc] init];
  //Retain count 2
  [self.blueView release];
  //Retain count 1

and in dealloc

  [self.blueView release];
  //Retain count 0

If I just did what you said, I'd get:

  self.blueView = [[BlueView alloc] init];
  //Retain count 2
  

and in dealloc

  self.blueView=nil;
  //Retain count 1, rut ro, memory leak

Which for KVO reasons is a really bad way of releasing objects when 'self' is being deallocated.

Hmm, I don't quite follow. I'm new to Cocoa programming and just followed the advice from the book Cocoa up and running.

If anyone does KVO on your object, they will be sent a "property changed" notification when you call self.myvar = nil in your dealloc method.

It's quite likely that whoever gets notified of the property change will attempt to access your object, but now your object is in a half-destroyed state.