From: Roedy Green on
On Tue, 02 Mar 2010 08:59:04 -0500, Eric Sosman
<esosman(a)ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

>
> List<String> list = new ArrayList<String>();
> for (int i = 0; i < 100; ++i)
> list.add(new String("unique"));
>
>? Both "one" and "one hundred" are reasonable answers.

Well done! I wanted to explain that, but started tripping over my
words and ended up deleting my explanation, thinking it would confuse
more than elaborate. You nailed it succinctly and clearly.
--
Roedy Green Canadian Mind Products
http://mindprod.com

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)
From: Lew on
Tom Anderson wrote:
> I ...
> read your comment as suggesting that the method should null-check the
> incoming argument.

That's what I recommended, yes.

> The right thing for this method to do if passed a null argument is to
> throw an exception. There is no uncertainty about that. And it already
> does that, so no check is necessary.

Not necessarily.

As Mike pointed out, some action may be needed upon discerning a null. To his
example, for example, I'd add logging in some scenarios. The method may be
one whose contract is to deliver some default value, such as Mike's suggestion
for the OP's case

boolean areListElementsUnique(List<?> l)

that a null argument be deemed trivially as containing no duplicate elements.
There is no reason for that check method to throw an NPE when it could
reasonably return 'true'. If that were the contract, the method would need
the null check. If that were not the contract, but the contract were to throw
NPE or IllegalArgumentException or MyApplicationException, then it would do that.

--
Lew
From: luc peuvrier on
On Mar 3, 1:08 am, Lew <no...(a)lewscanon.com> wrote:
> Mike Schilling wrote:
> >>>> boolean areListElementsUnique(List<?> l)
> >>>> {
> >>>>     return l.size() == new HashSet<Object>(l).size();
> >>>> }
> laredotornado wrote:
> >>> Winner! -
> Lew wrote:
> >> Don't forget to null-check the argument!
> Tom Anderson wrote:
> > The method already does that - if it's null, you get a
> > NullPointerException.
>
> Umm, the point of my comment was to *avoid* the NPE, duhh.  Why cause trouble
> for the method's client?
>
> --
> Lew

with this:

<T> boolean areListElementsUnique( List<T> list )
{
if (list == null || list.size() == 1 )
{
return true;
}
return list.size() == new HashSet <T> (list).size();
}

if list is null, areListElementsUnique return true, saying "list with
unique elemen", but list is null, not a single element list.

There is also the empty list case

Luc
From: Tom Anderson on
On Sun, 7 Mar 2010, Lew wrote:

> Tom Anderson wrote:
>> I ... read your comment as suggesting that the method should null-check
>> the incoming argument.
>
> That's what I recommended, yes.
>
>> The right thing for this method to do if passed a null argument is to throw
>> an exception. There is no uncertainty about that. And it already does that,
>> so no check is necessary.
>
> Not necessarily.
>
> As Mike pointed out, some action may be needed upon discerning a null. To
> his example, for example, I'd add logging in some scenarios. The method may
> be one whose contract is to deliver some default value, such as Mike's
> suggestion for the OP's case
>
> boolean areListElementsUnique(List<?> l)
>
> that a null argument be deemed trivially as containing no duplicate elements.
> There is no reason for that check method to throw an NPE when it could
> reasonably return 'true'.

I honestly can't imagine a situation where it would be reasonable for it
to do that. If your design involves passing around nulls to represent
empty lists, or lists in some other way not containing duplicates, then
your design is broken.

tom

--
The future is still out there, somewhere.
From: Mike Schilling on
Tom Anderson wrote:
> On Sun, 7 Mar 2010, Lew wrote:
>
>> Tom Anderson wrote:
>>> I ... read your comment as suggesting that the method should
>>> null-check the incoming argument.
>>
>> That's what I recommended, yes.
>>
>>> The right thing for this method to do if passed a null argument is
>>> to throw an exception. There is no uncertainty about that. And it
>>> already does that, so no check is necessary.
>>
>> Not necessarily.
>>
>> As Mike pointed out, some action may be needed upon discerning a
>> null. To his example, for example, I'd add logging in some
>> scenarios. The method may be one whose contract is to deliver some
>> default value, such as Mike's suggestion for the OP's case
>>
>> boolean areListElementsUnique(List<?> l)
>>
>> that a null argument be deemed trivially as containing no duplicate
>> elements.

That wasn't my suggestion.

>> There is no reason for that check method to throw an NPE
>> when it could reasonably return 'true'.
>
> I honestly can't imagine a situation where it would be reasonable for
> it to do that. If your design involves passing around nulls to
> represent empty lists, or lists in some other way not containing
> duplicates, then your design is broken.

I agree. A null isn't a List, and should throw an NPE.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Reflection accessing subclass
Next: java Date to c# ticks