Handle the KVO subclassing upon adding observers to a controller

[brianpattison]

When a key-value observer is added to a controller, the class becomes a NSKVONotifying class that doesn't have the task definitions. The task definitions can be found in the superclass.

[mattgreen]

Thanks for the patch.

But I think I'd prefer that we traverse the controller class' ancestors list, stopping with the first class that handles the task_definitions method. As is, the patch is coupled to implementation details of KVO we can't really control, namely the class name prefix.

Make sense?

[brianpattison]

That does sound better! :) If I remember correctly, the subclass still responded to task_definitions, but it was empty.

If that's the case, is there anything wrong with this logic:

If task_definitions[name.to_sym] is nil, traverse ancestors. Stop at the first class that responds to task_definitions and has the task key. OR stop traversing at the first class that doesn't respond to task_definitions and raise an error for missing task definition.

As far as raising an error, is there already an error class to use for a missing task definition?

Happy to help get this done right. Just let me know if this sounds the right direction!

[mattgreen]

Before we do that, let's try Just Using Ruby(tm):

def task_definitions
  @@task_definitions ||= {}
end

I expect that this will fix the problem. I think this is one of the few times a class var is preferred over a class ivar: we want it to apply to all subclasses.

[brianpattison]

I finally got around to this simple little fix... I updated the Travis CI config while I was at it.