Design for collections upgrades

[Sam Pullara]

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

Sam

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 gmail.com <mailto:alessiostalla at gmail.com>> 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
>> 
>> 
> 
>