Actually yes - Set<K> makes more sense for this API than K...
Varargs, IMO, are only useful in an API where users call the API. But if users have to
*implement* the API (as in this case) then collections make more sense. I would use Set
rather than Collection as it enforces (and informs the implementor) that there won't
be duplicates of K.
On 17 Jan 2011, at 13:57, Vladimir Blagojevic wrote:
Emmanuel,
Great points. The input keys K are known at compilation time. In this
contract implementers are most likely to save a reference to input keys
in a field variable rather than iterate through keys immediately. I
think that it might be a better idea to use Collection, no?
On 11-01-14 2:55 PM, Emmanuel Bernard wrote:
> I've taken a middle ground in Bean Validation.
> When a contract needed A and B for 90% of the forseable use cases (currently covered
and potential alike), we went for the following
>
> void contract(A a, B b, ContractContext context);
>
> It has proven to be quite robust for a few reasons including:
> - people know what's really important
> - we kept doors open for the future
> - various implementations used these doors to provide provider specific extensions
> - we will use these for BV 1.1 or 2
>
> Also, I am a bit worried about K...
> in theory it looks good but how are keys going to be carried. Are they known a
compilation time (where varargs shine) or are they likely going to be added to a Set and
passed around (in which case varargs is a pain as you need to convert from a set to an
array).
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org