If your are going to break binary compatibility then a major release is the time to do it. Is there any question that the design is wrong?
Gary On Apr 15, 2011, at 10:49, "Daniel F. Savarese" <d...@savarese.org> wrote: > > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
