On Mon, Oct 15, 2012 at 1:33 AM, Nick Coghlan email@example.com wrote:
On Mon, Oct 15, 2012 at 2:54 AM, Guido van Rossum firstname.lastname@example.org wrote:
On Sun, Oct 14, 2012 at 8:01 AM, Calvin Spealman email@example.com 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.
This problem does seem tailor-made for a Protocol ABC - you can inherit from it if you want, or call register() if you don't.
But you're still stuck with implementing the names that someone else decided upon a decade ago... :-)