Jörg Schaible a écrit :
IMHO we should define what we want to reach. Adding a method to an interface
does not break *binary* compatibility of existing code. The method is simply
not called. However, a client will have to implement the new method, if CConf
is a compile time dependency *and*
Hi Oliver,
Oliver Heger wrote:
Jörg Schaible schrieb:
Hi,
[snip]
IMHO we should define what we want to reach. Adding a
method to an interface does not break *binary* compatibility
of existing code. The method is simply not called. However, a
client will have to implement the new method,
Jörg Schaible schrieb:
IMHO we should define what we want to reach. Adding a
method to an interface does not break *binary* compatibility
of existing code. The method is simply not called. However, a
client will have to implement the new method, if CConf is a
compile time dependency *and* he
On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching [EMAIL PROTECTED] wrote:
So the rule would be:
* the project provides both an interface and an abstract class that
implements that interface.
* code that *uses* the API should always use just the interface, ie
*call* methods via the interface and
James Carman schrieb:
On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching [EMAIL PROTECTED] wrote:
So the rule would be:
* the project provides both an interface and an abstract class that
implements that interface.
* code that *uses* the API should always use just the interface, ie
*call*
On Wed, Nov 5, 2008 at 4:42 AM, Simon Kitching [EMAIL PROTECTED] wrote:
The standard JDK interface-based proxying would certainly become more
useful.
I meant changing Proxy's ProxyFactory from a class to an interface (or
perhaps introducing the IProxyFactory interface and leaving
ProxyFactory
On Wed, Nov 5, 2008 at 5:36 AM, Simon Kitching [EMAIL PROTECTED] wrote:
James Carman schrieb:
This pattern (replacing the implementation of specific methods) is not
supported out of the box by Proxy, but perhaps it should be? I
wonder how common it is that you'd want to replace the
On Wed, Nov 5, 2008 at 12:25 AM, Jörg Schaible
[EMAIL PROTECTED]wrote:
Hi Oliver,
Clirr is used to detect unintentional binary incompatibility. If we
document the facts (in site documentation and javadoc) everybody is informed
and should not be surprised if we actually follow this agenda.
Simon Kitching wrote:
[snip]
So the rule would be:
* the project provides both an interface and an abstract class that
implements that interface.
* code that *uses* the API should always use just the interface, ie
*call* methods via the interface and pass instances around as the
interface
Jörg Schaible schrieb:
Hi,
Ralph Goers wrote:
I believe this is the only discussion on 2.0 I've seen on the
dev list.
I went and scanned the archives a while ago. Rereading this thread I
don't really see a decision to use an Abstract class. I'm not sure I
understand the discussion about which
Hi,
Ralph Goers wrote:
I believe this is the only discussion on 2.0 I've seen on the
dev list.
I went and scanned the archives a while ago. Rereading this thread I
don't really see a decision to use an Abstract class. I'm not sure I
understand the discussion about which is more extendable.
James Carman schrieb:
On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible [EMAIL PROTECTED] wrote:
Hi Ralph,
Ralph Goers wrote:
FWIW, I agree. I must have missed the earlier discussion as well. I
definitely prefer having an interface that can be used whenever a
specific implementation is not
I believe this is the only discussion on 2.0 I've seen on the dev list.
I went and scanned the archives a while ago. Rereading this thread I
don't really see a decision to use an Abstract class. I'm not sure I
understand the discussion about which is more extendable. Yes, an
abstract class
On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible [EMAIL PROTECTED] wrote:
Hi Ralph,
Ralph Goers wrote:
FWIW, I agree. I must have missed the earlier discussion as well. I
definitely prefer having an interface that can be used whenever a
specific implementation is not required.
The original
Hi!
Look through the archives, the discussion with pros and cons went on
promoting commons-proxy.
Yes they did! I remember it well and I hated using a class rather
than an interface. However, I can see the merit in the decision when
it comes to maintenance and backward compatibility.
Hi,
I have not been in the conversations before, but I am also a proponent
of using interfaces. One way to enable extensions for those interfaces
would be to use the capability pattern (similar to what is described
here: http://java.dzone.com/news/the-capability-pattern-future- ).
There could be
16 matches
Mail list logo
