On Sun, Oct 14, 2012 at 8:01 AM, Calvin Spealman firstname.lastname@example.org wrote:
Why is subclassing a problem? It can be overused, but seems the right thing to do in this case. You want a protocol that responds to new data by echoing and tells the user when the connection was terminated? It makes sense that this is a subclass: a special case of some class that handles the base behavior.
I replied to this in detail on the "Twisted and Deferreds" thread in an exchange. Summary: I'm -0 when it comes to subclassing protocol classes; -1 on subclassing objects that implement significant functionality.
What if this was just an optional way and we could also provide a helper to attach handlers to the base class instance without subclassing it? The function registering it could take keyword arguments mapping additional event->callbacks to the object.
Yeah, there are many APIs that we could offer. We just have to offer one that's general enough so that people who prefer other styles can implement their preferred style in a library.