Multiple SAMs for same concept

[Reinier Zwitserloot]

True, most lists of 'these SAMs are distinct but really mean the same thing'
aren't 100% compatible with each other, but this in practice occurs all the
time. For example, Map itself does not mention whether or not one can use
null as either key or value. With HashMap, doing this is no problem, but
with Hashtable, or for example ConcurrentHashMap, do *NOT* allow null as
either key or value. When we receive an arbitrary Map object, and we decide
to transfer the contents to a ConcurrentHashMap, problems can occur
(specifically: NPEs). Nevertheless both the incoming map and the map we're
trying to put them in follow the same contract. HashMap and Hashtable both
implement the same interface, both do so entirely correctly, and yet they
aren't compatible with each other in some regard - in this case, null
keys/values.

In effect, then, something like "supplier#" is not just a compiler crutch,
it's conveying a useful construct: It's saying: I vouch for the notion that
these things will end up being compatible.

The compiler can't check every aspect of the contract, unfortunately.

NB: For what its worth, I don't really see the problem with { x ->
supplier(x)}, that's barely longer than supplier#, and is instantly obvious
to anyone that knows about closures, whereas supplier# is a new concept.
There's a (small) argument in favour of supplier# if the arglist grows
longer, but as the param list grows, the number of existing duplicate SAM
types shrinks rapidly, so that factor can be effectively ignored. We should
embrace the benefit of the SotL strategy that lets us omit the parameter
type.

 --Reinier Zwitserloot



On Fri, Jul 16, 2010 at 2:29 AM, Lawrence Kesteloot <lk at teamten.com> wrote:

> On Thu, Jul 15, 2010 at 5:11 PM, Collin Fagan <collin.fagan at gmail.com>
> wrote:
> > This is true for any interface.
>
> I disagree. An interface like Map defines the responsibilities of the
> client and of the implementing class. If this is ambiguous, then it's
> a bug in the interface. If these are violated by the client or
> implementing class, then it's a bug there.
>
> But in the case of autowrapping, interfaces A and B may both be
> specified well, both the client and implementing classes may properly
> implement the contracts, but the application code thoughtlessly hooks
> up the implementation of A with a client of B. Then A returns null
> (which it's allowed to do) and the client of B doesn't handle it
> properly.
>
> This isn't something that happens with interfaces as they work today.
> The application programmers shouldn't be allowed to too easily and
> thoughtlessly mix and match interfaces this way.
>
> Lawrence
>
>