On 23 Sep 2014, at 14:53, Mircea Markus <mmar...@redhat.com> wrote: > On Sep 23, 2014, at 15:18, Emmanuel Bernard <emman...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
