Design for collections upgrades

Sam Pullara sam at
Thu Mar 10 11:04:46 PST 2011

I also agree. Making these operations eager sort of defeats the purpose of introducing them IMHO.


On Mar 10, 2011, at 10:57 AM, Rémi Forax wrote:

> I agree.
> Rémi
> On 03/10/2011 07:56 PM, Pavel Minaev wrote:
>> So if I call filter on a TreeSet reference, then I get a TreeSet; but 
>> if I upcast it to Set and call filter, I get HashSet?
>> I think it's too subtle, and likely to go unnoticed. Especially since 
>> common practice in Java code is to type variables as relaxed as 
>> possible, even for locals (i.e. Set rather than TreeSet).
>> This also changes the usual conventions for collection operations, 
>> where the precise semantics of the operation is defined by the dynamic 
>> type of the collection, not static type of the reference. For example, 
>> if I call add() on a List reference which refers to an ArrayList, I 
>> know that the element is added to the end of collection, and that 
>> complexity is amortized constant time. But with this proposal for 
>> filter() etc, that would no longer be true - static type of reference 
>> would define behavior.
>> If there's no way to implement it such that it depends only on the 
>> dynamic type of object, then I think it would be better to have a 
>> single uniform behavior for all collections - and that would have to 
>> be lazy, so that you can build eager (with collection type explicitly 
>> specified) on top of that.
>> On Thu, Mar 10, 2011 at 3:32 AM, Alessio Stalla 
>> <alessiostalla at <mailto:alessiostalla at>> wrote:
>>    Well, extension methods are polymorphic, is that right? Then, you
>>    could have a different extension method per Set implementation, and a
>>    default one for Set that uses HashSet. If such an extension method
>>    existed, it should not be tied to filter in particular; I'm thinking
>>    of a generic newInstance() method. It could in fact be generalized for
>>    Collection.
>>    Alessio

More information about the lambda-dev mailing list