Design for collections upgrades
forax at univ-mlv.fr
Thu Mar 10 10:57:43 PST 2011
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
More information about the lambda-dev