commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [net] binary compatibility be damned
Date Mon, 18 Apr 2011 10:10:51 GMT
On 15 April 2011 20:34, Daniel F. Savarese <dfs@savarese.org> wrote:
>
> In message <-2240415941472220542@unknownmsgid>, Gary Gregory writes:
>>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?
>
> I got the impression the change was made the way it was solely to work
> around binary compatibility issues (hence the provocative thread subject),
> not because it was believed to be the optimal approach.  From that
> perspective, it's not "wrong."  None of this stuff is ever really right
> or wrong; it just involves a different set of trade-offs.  Since the
> Commons Net class structure is one of using classes primarily as modules
> containing related code for reuse (i.e., instantiable namespaces), not
> one of using classes for polymorphic generic programming, I think it best
> for maintenance and code understanding purposes to create a new module/class
> isolating common code for "protocol command clients" instead of placing it
> inside of the more general SocketClient. My real preference would be to use
> delegation, but Java doesn't have a way to automatically delegate to a
> member and manual delegation results in the code duplication that
> motivated the refactoring.
>
> If we can break binary compatibility, since this is a major release,
> this would be a good time to do a thorough code review.  I know sebb's
> been doing a lot of that, but the more eyes the better.

Of course we *can* break binary compatibility, but for a component
like Net which is fairly low-level, IMO we should only do so if it's
really necessary, because of the additional work that it causes all
downstream users.

I originally thought it was going to be necessary to break binary
compat. to fix NNTP, but it turned out that it was not, so I really
don't want to break it for a code refactoring. I'd rather revert to
duplicating the code in all the classes that need it, though in the
general scheme of things I don't think the work-round is unreasonable.

If there is a better way of doing the refactoring without breaking
binary compat. then let's do that.

If anyone wants to completely rewrite Net to tidy it up, fine, it can
be released as a completely new product (which is effectively what
breaking binary compatibility means for the end-user).

If binary compat. is to be broken, then it needs to be done once, and
done properly so it does not have to be done again. That's not
something I personally have any inclination to tackle at present, so
I'm trying to ensure binary compat. whilst fixing as many of the bugs
as possible.

> 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


Mime
View raw message