Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!weretis.net!feeder4.news.weretis.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.lang.java.programmer From: Andreas Leitgeb Subject: Re: Call by Result References: <95e4uuF3cvU1@mid.individual.net> Reply-To: avl@logic.at User-Agent: slrn/pre0.9.9-111 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: 10 Jun 2011 13:12:16 GMT Lines: 23 NNTP-Posting-Host: gamma.logic.tuwien.ac.at X-Trace: 1307711536 tunews.univie.ac.at 73248 128.130.175.3 X-Complaints-To: abuse@tuwien.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5177 Arved Sandstrom wrote: > I'll accept that returning an object containing both the possible > modified String and a boolean status is OK. I don't much like it, Why would such a returned object contain a possibly *modified* String? It would expectably contain whatever String the method getString wants the caller to see. It doesn't get one from outside in this case (as opposed to my #2 case), so there's nothing to "modify". > however, for two reasons. It's still the use of a return value for > operation status, and although that's defensible, there's nothing OO > about it - it's pure imperative programming. And were we to still pursue > that approach, unfortunately Java has no elegant means for supporting > it, unlike Haskell Maybe or Scala Option. Not sure, what feature you're principially talking of. Is it some kind of syntactic sugar to further simplify code like this: BoolStr bs = getString(); boolean b=bs.bool; String s=bs.str; ? (just curious)