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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Galder Zamarreno
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Eduardo Martins
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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Galder Zamarreno
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Eduardo Martins
I was considering the listeners setup as part of the config! Of
course, then I had to take the chance to recommend once again to
settle for a single programmatic configuration process right now hehe
;-)

-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco



On Tue, Jul 19, 2011 at 11:13 AM, Galder Zamarreño <[hidden email]> wrote:

> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Mircea Markus
In reply to this post by Galder Zamarreno
This is isolated and won't break API compatibility so I think it makes sense.

On 19 Jul 2011, at 09:50, Galder Zamarreño 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Manik Surtani
I would rather leave this alone for now.  Once JSR-107 is complete we'll need to change Listenable to be compatible anyway so may as well just do it once.  

And re: fluent API for listeners, why not suggest that on the JSR-107 Google Group.  :)

On 19 Jul 2011, at 13:16, Mircea Markus wrote:

> This is isolated and won't break API compatibility so I think it makes sense.
>
> On 19 Jul 2011, at 09:50, Galder Zamarreño 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

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

Galder Zamarreno

On Jul 19, 2011, at 2:35 PM, Manik Surtani wrote:

> I would rather leave this alone for now.  Once JSR-107 is complete we'll need to change Listenable to be compatible anyway so may as well just do it once.  

Ok.

>
> And re: fluent API for listeners, why not suggest that on the JSR-107 Google Group.  :)

Sure, I'll post the suggestion there.

>
> On 19 Jul 2011, at 13:16, Mircea Markus wrote:
>
>> This is isolated and won't break API compatibility so I think it makes sense.
>>
>> On 19 Jul 2011, at 09:50, Galder Zamarreño 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev