commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject [net] binary compatibility be damned
Date Fri, 15 Apr 2011 14:48:56 GMT

Prior to the 3.0 release, I'm trying to review recent code changes and
test the code in what little spare time I have available.  I noticed that
ProtocolCommandSupport __commandSupport was moved into SocketClient.
I disagree with this change.  SocketClient isn't meant to serve only
Commons Net classes, nor is it meant only for implementing clients for
IETF protocols; and only a limited number of clients actually need
to use ProtocolCommandSupport.  Having a private member variable that is
initially null that must be initialized outside of the base class via calling
createCommandSupport to initialize is fragile.  That's what constructors
are for.  Even though Java doesn't have destructors, avoiding initialization
protocols and using RAII is still a good rule of thumb for resource creation.

A more robust and flexible separation of concerns would place the
ProtocolCommandSupport member in a ProtocolClient abstract class that
subclasses SocketClient and initializes __commandSupport (which should
be protected, not private, obviating the need for getCommandSupport())
in its constructor.  Then the protocol clients that require
ProtocolCommandSupport can be changed to subclass ProtocolCommandSupport.
That won't break compilation of any user code, but breaks binary compatibility.
Emphasizing binary compatibility at the expense of design doesn't make sense
to me.  Commons Net is enough of a Rube-Goldberg machine as it is.

Is there some overriding reason why binary compatibility absolutely must
be maintained or may I open an issue and make the above change?

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message