[infinispan-dev] Too late for an 5.0 API change?

Galder Zamarreño galder at redhat.com
Tue Jul 19 06:13:40 EDT 2011


Eduardo,

That's a different topic to the one I was asking the dev list.

Sure, all config can be done via fluent, hence why the rest of config methods have been deprecated.

I think breaking programmatic config compatibility would be the wrong thing to do now, hence why we deprecated it, to allow people to move over their code during the 5.x lifecycle.

We'll remove the old configuration methods in 6.x.

Cheers,

On Jul 19, 2011, at 11:11 AM, Eduardo Martins wrote:

> Hi Galder, what worries me is that now exist even more ways to config
> than a few months ago ;) IMHO you should discard the deprecated ones
> now if possible, 5.0.0 is a major version, it is fine to break
> compatibility with 4.x, doing it later will be a  major pain, unless
> you wait for 6.x, but this is a bit messy as it is now. Since fluent
> seems the new config model I would assume you can do all the
> configuration using it, otherwise the user code looks strange.
> 
> -- Eduardo
> ..............................................
> http://emmartins.blogspot.com
> http://redhat.com/solutions/telco
> 
> 
> 
> On Tue, Jul 19, 2011 at 9:50 AM, Galder Zamarreño <galder at redhat.com> wrote:
>> Hi all,
>> 
>> What do people think of changing the addListener() APIs to be more fluent?
>> 
>> We could either:
>> 
>> 1. Change Listenable to be Listenable<T> and then have:
>> 
>>    <T> addListener(Object listener);
>> 
>> So, implementers such as EmbeddedCacheManager would implement Listenable<EmbeddedCacheManager> and so would implement:
>> 
>>    EmbeddedCacheManager addListener(Object listener);
>> 
>> 2. Or, more simply, have Listenable define:
>> 
>>    Object addListener(Object listener);
>> 
>> and EmbeddedCacheManager using covariants to implement:
>> 
>>    EmbeddedCacheManager addListener(Object listener);
>> 
>> Btw, the same would apply to removeListener.
>> 
>> Thoughts?
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list