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* he
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
> interf
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 ag
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 t
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 implementation
> of certain methods and you wouldn't just go ahead and extend
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
ProxyFact
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
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 interfa
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 depend
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
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 extendab
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 mea
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 re
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
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 compatibi
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.
>
>
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 arguing was, that an interface will always prevent an
enhancement becaus
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.
Michiel Kalkman wrote:
I don't know the discussion, so the only thing I can say right now, is
that I don't like the na
I don't know the discussion, so the only thing I can say right now, is
that I don't like the names ... Or I just don't understand why it is
called XXXSource, which in my thoughts refers to the resource the
configuration is read from.
How about Configuration for the interface and something like
Bas
20 matches
Mail list logo
