SuperCoreStack should be 100% decoupled from NSFetchedResultsControllerExtension

[rromanchuk]

This extension is a great class, but it needs to be decoupled. https://github.com/michaelarmstrong/SuperRecord/blob/master/SuperRecord/NSFetchedResultsControllerExtension.swift#L102

We use a more advanced stack so this line gives us problems. In general it's probably better to force the callee to be responsible for sending the MOC, always. In general calling back up to the delegate for the moc is bad practice, especially when there isn't just a single MOC being used everywhere.

[michaelarmstrong]

The callee CAN be responsible for sending the MOC, but if you don't it will default back to another. However, this pattern will change soon as i'm developing a new pattern for this area (see issue: #22 ).

In regards to calling back up to the delegate, would you prefer the receiver sets the delegate on a returned object from that method manually? If you could could write up a quick 10 line example of your suggestion it'd help.

[rromanchuk]

@michaelarmstrong the problem is with the actual default, I don't include that class in my project. I actually like NSFetchedResultsControllerExtension setting up the binding, i just had to rip the the stack out of that class so it wouldn't crash. No one ever does this, but developers should be "data passing" their moc between controllers, this paradigm would align with forcing the user to explicitly make a decision about what moc the NSFRC will be listening too. On my project my fix was just removing the default

[rromanchuk]

This is my usage

lazy var fetchedResultsController: NSFetchedResultsController = NSFetchedResultsController.superFetchedResultsController("Post", sectionNameKeyPath: nil, sortDescriptors: self.sortDescriptors, predicate: self.predicate, tableView: self.tableView, context: self.managedObjectContext)