It has a lot of the benefits of CI, while missing some of the downsides. You get a nice set of command-line tools (and the framework to write your own shells and tasks) for interacting with your app, “baking” various things like stub models / controllers / views, and dealing with schemas.

You also get model relationships which can also be bound and unbound on the fly, your result sets can be “containers” for other things (so you specify exactly what you want back from the relationships).

It’s also pretty easy to create your own data sources, this ecample from the docs shows you a method for using Twitter data for your model:

http://book.cakephp.org/view/849/An-Example

http://cakephp.org/

// Optimal method, undeclared in interface. First thread through the // method below will swap the implementation of the below method with // that of this one, so we take the expensive path only once.

• (BRUnits *)centimetersInstance { return _BRUnits_centimeters; }

// Clients will always call this method. During execution by the first // thread to land here, swap in the implementation of the method above. // Normally one would handle this instantiation in an initialize method, // but when a category like this one has an initialize, any initialize // method present in the categorized class won’t get run, and we also // have no access to it. That is, in general, really weird and thus // to be avoided.

• (BRUnits *)centimeters { @synchronized(self) { if (_BRUnits_centimeters == nil) { _BRUnits_centimeters = [[[BRUnits_centimeters class] alloc] initWithName:@”centimeters”];

      OSMemoryBarrier();
  
      Method m1 = class_getClassMethod([BRUnits class],
                                       @selector(centimeters));
      Method m2 = class_getClassMethod([BRUnits class],
                                       @selector(centimetersInstance));
  
      method_setImplementation(m1, method_getImplementation(m2));
  }
  

  }

  return _BRUnits_centimeters; }

The point about sending messages to super is important. Although it makes perfect sense, I doubt I’d have thought about it before blindly sending a message and then being confused by the results. I guess I’ve never needed to call super from an extension method before.

In general, I’m using this kind of technique to extend my own classes so I’m probably safe from the ivar issues. But it’s definitely great to know all the places you might get into trouble.

but — ivars are the major one and will cause all sorts of head aches if one is not careful.

For super, I define a macro

define SUPER(…) objc_msgSendSuper(&(struct objc_super){self, class_getSuperclass([self class])},_cmd, ##VA_ARGS)

that will automatically look up the super of the class at runtime and call the appropriate method

rather than -(void) doThis: (id)param1 andThat:(id)param2{ //used to be [super doThis: param1 andThat: param2]; // now SUPER(param1,param2); }

Only issue with this is on a dealloc — compiler will complain if you have your dealloc method doesn’t have a [super delloc] — trick is to do both with a return statement after the SUPER() call.

-(void)dealloc{ SUPER(); return; [super dealloc]; }