On 23 Sep 2014, at 14:53, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Sep 23, 2014, at 15:18, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>> I am not sold on this as it seems pretty trivial to decipher which
>> operation is which and the information would be present on the
>> javadocs as well.
>
> I very strongly disagree. Cf the other thread with Radim 's comment on topology
error.
> And think about *future* evolutions. The enum would make that much safer. In the bin
enum world you would have to introduce a new YetAnotherKeyValueFilter interface :)
Nicer than an enum would be an explicit method, e.g.
handlePut/handleDelete/handleCreate/handleUpdate, as these would also receive the
appropriate param list.
^ Hmmmmm, not sure I like that. If you look at the remote event blog posts, you’ll see
that I use create/modify/remove annotations and then the parameter to the callback varies
depending on whether you had converter applied to it or not. IOW, without a converter, a
created event parameter is a ClientCacheEntryCreatedEvent, whereas with a converter, the
parameter is a ClientCacheEntryCustomEvent. Two different types of events for the same
event type. If you did it with explicit methods, you’d have to duplicate them for custom
events.
Of course this means moving away from the KeyValueFilter to an
UpdateFilter (good name, Radim) used only for cluster listeners.
I don’t like the name actually. I associate update with modifications, and in similar
vein, inserts with creation and delete with removals.
Will, what would be the overall impact on the API as right now the
KeyValueFilter is reused between several components, like the cluster iterator.
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz