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 gudnabrsam@gmail.com designates
 209.85.161.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:content-type:message-id
         :content-transfer-encoding:from:subject:date:to:x-mailer;
        b=oJlLFeVqvHTIG7n4SI8KH46oNvfHKS9SNwpJsujPI6tpnV3a4zhlym4wXINBTQ6D5N
         uW40uXfGDNmx486/hboFnRDw1bApi5fszE4ByRSVEPBI4nuT4JnnM0gg5jhBdsy/BAxS
         kaQGgsIpO1AG6nunAM/C2lYYFyWm1DAXsFTJE=
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <AANLkTik6lPlzVcxo3ozIfGW96Olvujx4qxxM3lcvsY5z@mail.gmail.com>
References: <AANLkTik6lPlzVcxo3ozIfGW96Olvujx4qxxM3lcvsY5z@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7D5EF163-7C8B-4337-94EE-5EFFEE24EAFC@gmail.com>
Content-Transfer-Encoding: 7bit
From: Matt Benson <gudnabrsam@gmail.com>
Subject: Re: [proxy] Changing the API to an interface (AGAIN)...
Date: Wed, 14 Jul 2010 22:12:09 -0500
To: "Commons Developers List" <dev@commons.apache.org>


On Jul 14, 2010, at 9:21 PM, James Carman wrote:

> All,
>
> One of the biggest complaints I've received from folks about the proxy
> library is that it's not based on interfaces.

What is the typical basis of a complaint?  I.e., what problem does  
the abstract class cause?

> The main class is the
> ProxyFactory class and it's a concrete class which implements all
> proxying logic using JDK proxies.  We did this for maintainability
> (adding stuff to the interface breaks binary compatibility as opposed
> to adding a method to a concrete superclass with an implementation).
> I would like to re-structure proxy so that it contains a few
> modules...
>
> 1.  Commons Proxy Core - the API itself containing the ProxyFactory  
> *interface*
> 2.  Commons Proxy JDK - the JDK proxies implementation
> 3.  Commons Proxy CGLIB - the CGLIB implementation
> 4.  Commons Proxy Javassist - the Javassist Library
>
> With the new paradigm of just bumping major version numbers (and
> package names) allowing us to break compatibility, I don't think the
> interface issue is that much of an issue anymore.  What do you guys
> think?

I personally don't feel strongly about the interface vs. abstract  
class issue; I can understand both sides of the debate.  I am curious  
as to the nature of folks' dissatisfactions with the abstract class  
approach, however.  I do take your point regarding package renaming  
allowing the expansion of an interface without having to version  
interfaces e.g. ProxyFactory2, ProxyFactory3, etc...

I would support [proxy] becoming a multi-module project; among other  
things we could selectively have a larger set of dependencies this  
way.  How would you feel about the module that contains the recording  
functionality depending on [lang] 3.x for type utilities?

-Matt

>
> Thanks,
>
> James
>
> ---------------------------------------------------------------------
> 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