+Matt Trout expressed following criticism of the support for many to many in
+RecursiveUpdate and since this is an extension of his DBIx::Class I feel obliged to
+reply to it. It is about two points leading in his opinion to 'fragile and
+implicitely broken code'.
+
+1. That I rely on the fact that
+
+ if($object->can($name) and
+ !$object->result_source->has_relationship($name) and
+ $object->can( 'set_' . $name )
+ )
+
+then $name must be a many to many pseudo relation. And that in a
+similarly ugly was I find out what is the ResultSource of objects from
+that many to many pseudo relation.
+
+2. That I treat uniformly relations and many to many (which are
+different from relations because they require traversal of the bridge
+table).
+
+To answer 1) I've refactored that 'dirty' code into is_m2m and get_m2m_source so
+that it can be easily overridden. I agree that this code is not too nice - but
+currenlty it is the only way to do what I need - and I'll replace it as soon as
+there is a more clean way. I don't think it is extremely brittle - sure it will
+break if many to many (pseudo) relations don't get 'set_*' methods anymore - but
+I would say it is rather justified for this kind of change in underlying library
+to break it.
+
+
+Ad 2) - first this is not strictly true - RecursiveUpdate does have
+different code to cope with m2m and other cases (see the point above for
+example) - but it let's the user to treat m2m and 'normal' relations in a
+uniform way. I consider this a form of abstraction - it is the work that
+RecursiveUpdate does for the programmer.
+
+
+=head1 INTERFACE