JDK flaw: missing CanContainCopies interface?

[Mr Smith]

When you use a collection, and the only think you need to assume is that the Collection can handle copies:

public void add(Collection c) {
c.add(new Integer(1));
c.add(new Integer(1));
}

why didn't anybody complained about the lack of interface, or method like "isSupportingCopies()" in Collection interface?

 

[John C. Bollinger]

When you use a collection, and the only think you need to assume is that the Collection can handle copies:

public void add(Collection c) {
c.add(new Integer(1));
c.add(new Integer(1));
}

why didn't anybody complained about the lack of interface, or method like "isSupportingCopies()" in Collection interface?

(1) You can determine whether a Collection.add() operation actually
modifies the Collection by examining the return value. More
importantly, however

(2) A method such as you describe is poorly conceived. No method needs
to depend on that aspect of the behavior of a Collection argument. If
the purpose of the argument is to return values to the invoker then the
_invoker_ controls whether or not duplicates are permitted by the choice
of Collection. In any case where the method wants a mutable collection
for internal use, it *needs* to create its own from the elements in the
provided Collection, and then it has full control over what kind of
Collection to use.

(3) The appropriate semantics of such an interface or method may not be
clear in all cases. Take an immutable List, for example: if an instance
does not actually contain duplicates, should it indicate that it
supports them or not?

 

[Mr Smith]

(1) You can determine whether a Collection.add() operation actually
modifies the Collection by examining the return value. More

true, but not handy

(2) A method such as you describe is poorly conceived. No method needs
to depend on that aspect of the behavior of a Collection argument. If

so what? it's a good thing?

the purpose of the argument is to return values to the invoker then the
_invoker_ controls whether or not duplicates are permitted by the choice
of Collection. In any case where the method wants a mutable collection
for internal use, it *needs* to create its own from the elements in the
provided Collection, and then it has full control over what kind of
Collection to use.

yes but not handy, several checks needed instead of one in the constructor for example

(3) The appropriate semantics of such an interface or method may not be
clear in all cases. Take an immutable List, for example: if an instance
does not actually contain duplicates, should it indicate that it
supports them or not?

of course


because of this, i don't use Collection, but List and Set, and i don't mix them, which sucks.

 

[John C. Bollinger]

true, but not handy

Invaluable if you actually need it, but it is rare to need it.

so what? it's a good thing?

No, a method with the kind of dependencies / assumptions you describe is
a bad thing. The absence of support for it in Collection is therefore a
non-issue. There might conceivably be a more appropriate context for
your criticism of Collection's lack of the feature you desire, but I'm
not seeing it.

yes but not handy, several checks needed instead of one in the constructor for example

No, no checks are required. If the method needs a collection for
internal purposes then it doesn't matter whether the one passed in has
suitable characteristics -- the method still needs to create its own.

of course

"Of course" that's a problem, or "of course" the object should indicate
that it supports duplicates? The latter position is not self-evident to
me because given a List such as I describe, I cannot cause it to contain
duplicate elements. Is it then right to say that it supports them?
Perhaps the _class_ allows duplicate elements, so maybe the object
_should_ claim to support duplicates, but that isn't relevant to what I
can do with it.

because of this, i don't use Collection, but List and Set, and i don't mix them, which sucks.

Collection is a rather abstract interface, and it is intended to be so.
There are plenty of valid contexts for its use. There are also plenty
of contexts where use of List or Set instead is appropriate. I don't
see anything wrong with having to be more specific in some places, but
being free to be more abstract in others. It matches well with
component requirements and guarantees.

If you are not using direct Collection implementations then I see no
basis at all for your complaint. If you need an argument to be a List
then declare it a List. There is no advantage whatever to declaring it
a Collection and then checking after the fact that it is actually a List.

If you bring direct Collection implementations into the picture then
there is at least some cause for concern, but for the most part the
preceding paragraph still applies. There has been no outcry from the
community on this particular issue because it is rarely a problem in
practice.

Now on the other hand, don't get me started on mutable vs. immutable
collections and UnsupportedOperationException....