Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Is there a better way to group and sort objects? Date: Tue, 7 Aug 2018 16:00:50 -0400 Organization: A noiseless patient Spider Lines: 54 Message-ID: References: <8c045ff4-98c5-4253-9136-b26b34cf8f77@googlegroups.com> <31b0fbe7-3e14-4b60-9779-8435fcd04e22@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 7 Aug 2018 20:00:54 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="f0a04ad17fb0ec6fb0ccf598402412ff"; logging-data="28133"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BSdlrUogQCGcXrcOpf0mz" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cancel-Lock: sha1:iuszw2ityV5vfpbjkV+gbc8PUL4= In-Reply-To: <31b0fbe7-3e14-4b60-9779-8435fcd04e22@googlegroups.com> Content-Language: en-US Xref: csiph.com comp.lang.java.programmer:38526 On 8/7/2018 3:13 PM, Eric Douglas wrote: >> It still fails to be antisymmetric: >> >> TestClass obj = new TestClass(); >> TestClass nil = null; >> int one = obj.compareTo(nil); // yields +ve >> int two = nil.compareTo(obj); // should yield -ve, but throws >> >> (This discussion seems oddly familiar: Have we had it before? Ah, yes: >> Google Groups finds a thread from two years ago titled "Why not String >> compare?" and another from one year back titled "What's the best way to >> make a cross string set?" Both threads discuss implementing Comparable >> and/or Comparator, and the latter touches upon the impossibility of >> implementing Comparable. Will this query be an annual event? :) >> > Ah ok, in this case there should never be a null. ... in which case, it's hard to understand why you check for it. > I keep thinking when a method passes in any sort of Object I should account for null as some possibility. I believe you're suggesting the compareTo method just start with this: > if (compareMe == null) { > throw new Error("don't compare me to a null!"); > } I *think* that's all right. Since nil.compareTo(obj) will throw, obj.compareTo(nil) must also throw -- but I don't see a requirement that it throw the same Throwable type. An `assert' would also be okay, I think, because (1) if it's enabled and throws AssertionError that satisfies the requirement to throw, and (2) if it's disabled you'll get NullPointerException as soon as you try to access the fields or methods of the null reference. Objects.requireNonNull() is yet another possibility. What you must not do is what you wrote originally: Pretend the null reference is to a "null object" and "compare to" that thing. The null reference is to "no object at all," and you cannot compare to "no object at all" -- unless "no object at all" can compare itself to your object, and consistently. >>>> Alternatively, you might take advantage of the fact that Map::put >>>> returns the old key (if any) associated with its value: >> >> Aside: Um, er, Map::put returns the old *value* (if any) associated >> with its *key*, yeah, that's what I meant, yeah, obviously, of course. >> "I misspoke," as the President so eloquently and so often says. > > Right? I believe we both said the same thing and meant something else. The return value of the put method is the value of the key at the put position (which may be null). No. That's what I wrote initially, and that mis-statement is what I corrected above. (Dyxlesia is a dyslexic's self-diangosis.) -- esosman@comcast-dot-net.invalid Eight hundred ninety-seven days to go.