Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Gene Wirchenko Newsgroups: comp.lang.java.programmer Subject: Re: Call by Result Date: Fri, 10 Jun 2011 11:31:34 -0700 Organization: A noiseless patient Spider Lines: 62 Message-ID: References: <95e4uuF3cvU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="7Qrvczazr82YckO5XW8Vtw"; logging-data="7422"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2fKvxTkIfpPJRRcDpZMNmdZX0hpRxGLE=" X-Newsreader: Forte Agent 4.2/32.1118 Cancel-Lock: sha1:oI/JOqh9odsiFHm952Lg6uK89mE= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5193 On Fri, 10 Jun 2011 08:23:17 -0300, Arved Sandstrom wrote: [snip] >This is the kind of thing where "purists" will get a bit bloody. Not to Let them scream. I have other comments elsethread. In short, if your favourite way of doing things causes me a bunch of extra work to use, I am liable to not use it. >teach you or any other respondent here how to suck eggs, but I'll throw >in, for general edification of a wider audience, the information that >we've got this problem both because Java has "pass object reference by >value" and Strings are immutable. Hence the OP's question. Nope. I simply want to call by result. >Given that, Andreas' #2 is legit (I agree, Nigel, with your concerns >regarding #1 and #3), and so are the two suggestions you and Patricia >have put forth. I based my answer on #2. >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, >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. Well, imperative programming does exist, and I use it. >The failure of Java to cleanly support the previous approach pretty much >argues, IMHO, for exceptions. And this is, again IMHO, quite pure. It's Nope. Too complicated. >basically my business to define what I consider to be failures and >errors. Myself I see absolutely no problem in arguing that a failure to >work (parse) is a failure. :-) It's certainly an error in the input to >be parsed. In any case the OP would hardly be asking for an operation >success status if it wasn't possible for the method to fail. > >Another argument for exceptions here is the OP's > >if (!DidItWork) > // too bad > >bit. I have my doubts as to whether the OP's intended error processing >consists just of a NOOP and a comment. Assuming that it doesn't, and one >actually wants to do something productive in the error-handling, >exceptions are the best way to do it. Get real! It is common in examples to have a comment indicating what would be done when said code is not particularly relevant to the example. Sincerely, Gene Wirchenko