[infinispan-dev] Distributed execution framework API - final review

[Manik Surtani]

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 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

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

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