Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Roedy Green Newsgroups: comp.lang.java.programmer Subject: Re: toward null-safe cookie cutter Comparators Date: Mon, 14 Nov 2011 10:28:16 -0800 Organization: Canadian Mind Products Lines: 80 Message-ID: References: Reply-To: Roedy Green NNTP-Posting-Host: Z2l1DcCELS0rATq8NqV4Sw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Forte Agent 6.00/32.1186 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9959 On Sun, 13 Nov 2011 17:59:54 +0000, Tom Anderson wrote, quoted or indirectly quoted someone who said : >return aSpecies.compareTo( bSpecies ); > >Perhaps even pushing the duplicated denullification into a little method. >Note that when the Elvis operator makes it into Java, you will be able to >write: This whole business of multiple representations for empty. Acch(Imagine a Yiddish sound of contempt). null, "", " " I have have always felt this looseness was like a trap a child digs to catch the mailman. There are no assertions defining what a given method parm will accept (though IntelliJ is pushing @Nullable and #NotNull) There is not even a JavaDoc convention to warn you if a method might produce which combinations of the three. see http://mindprod.com/jgloss/empty.html From a machine efficiency point of view, null is probably the best convention. Empty is usually a special case anyway. It might as well be easy to detect. From a coding safety point of view "" is best. It will generaly work sensibly if passed to a method expecting a substantial string, where there is a good chance it would fail on null. Maybe we need some sort of Generics to declare what methods produce/consume and have thecompiler tell you if you are potentially doing something dangerous at compile time. I once drove my boss nearly to distraction, because I was convinced the problem with the project was random empty string representations. The DWIM school of thinking Way back I wrote suggesting a DWIM approach to taming the dreaded NullPointerException. It is inspired more by scripting languages. Thing a = null. a.getAString() --> null a.getTemp() --> 0.0d; a.getDufusOBject --> null a.doSomething() --> does nothing a.doSomethingElse ( engage( 42 ) ); --> invokes engage function ( in my mind checking a and store come after RHS evaluation, If I had my way Java would a much stricter left to right evaluation order) For more explicit use, you would replace the . operator with .? to indicate you wanted to do a dummy var fetch/method call or none at all if "a" were null. When I thought about extending that I though perhaps classes should use dummy objects in place of null to bypass this sort of trouble at clealr all that null-handling clutter,just letting the null-handling logic come out in the wash most of the time. The thinking is a bit like the way there are are multiple flavours of NaN in IEEE floating point, and the value appearing in calculation is not the end of the world. The null just propagates. P.S. Apparently the eponymous Elvis rarely went to Las Vegas. I have not tracked down who he is. People were often puzzled when I talked about the McCarthy or operator || the bitwise | one. see http://mindprod.com/jgloss/or.html The McCarthy I refer to probably never met Candice Bergen and died recently. -- Roedy Green Canadian Mind Products http://mindprod.com I can't come to bed just yet. Somebody is wrong on the Internet.