actually this isn't a leak as the data source really shouldn't reference the table view. It looks like CCTableView becomes the owner of the data source (consumes it). It seems different than a standard delegate pattern. If the data source wasn't strong, there's probably a good chance this would break this view.

First of all, the scroll view uses a delegate which is weakly retained. Commonly delegate and source are the same.

Secondly, since CCTableView is supposed to mirror UITableView, which uses a weak reference, this would surprise most people.

Thirdly, this only makes sense is the CCTableView at the top of the hierarchy, which means it pretty much needs to be subclassed. To subclass CCTableView aside from custom behaviour signals a pretty broken design.

As for the pull request, I'm actually using my own custom version of cocos2d, but I wanted to share this so that no-one else has to run into this issue (it retained an entire scene graph for me, and I wouldn't have easily have detected it if it wasn't for another memory detection check I did)

The CCTableView will dealloc when it's removed from a scene. When the CCTableView is deallocated, the dataSource is deallocated along with it. (provided there is no other references to the dataSource).

But ya, if UITableView has a weak data source, it should probably follow that design. There's nil checks and respondsToSelector checks in the implementation, so it seems like it was supposed to be a weak ref anyways.

Is that your actual design? I mean, of course I know how I can avoid problems with strong retain if I need to, it just seems like doing something like that would be a rather convoluted way of handling the problem. Is it a natural design for you? Do you have reasons why you easily can hand over the data source in this manner?