Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of garydgregory@gmail.com
 designates 209.85.215.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=references:from:in-reply-to:mime-version:date:message-id:subject:to
         :content-type;
        b=hAVrp2hu87CtWvNALQcGhEHxm0cdcIH68UFx8Zz87/mqAB5fe+O1/GEBE/qUv/L22a
         yi/MMs8m94iAlpppLmm2+eRUnlsxpx278Mz4g/6znVbdPaf8Otr5FasEJoNfKfZyVBqK
         ag0WYxY7WPbgNFdLLrSXvrjoq5414aBotFhBY=
References: <201104151448.p3FEmuOS005381@aragorn.savarese.org>
From: Gary Gregory <garydgregory@gmail.com>
In-Reply-To: <201104151448.p3FEmuOS005381@aragorn.savarese.org>
Mime-Version: 1.0 (iPhone Mail 8H7)
Date: Fri, 15 Apr 2011 13:11:08 -0400
Message-ID: <-2240415941472220542@unknownmsgid>
Subject: Re: [net] binary compatibility be damned
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8

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" <dfs@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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