Design for collections upgrades

[Pavel Minaev]

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