Design for collections upgrades

[Rémi Forax]

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