Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15027 > unrolled thread

Holy boop: goto for Java

Back to article view | Back to comp.lang.java.programmer

Contents

  Holy boop: goto for Java markspace <-@.> - 2012-06-03 19:36 -0700
    Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-03 20:03 -0700
      Re: Holy boop: goto for Java markspace <-@.> - 2012-06-03 20:30 -0700
        Re: Holy boop: goto for Java Lew <noone@lewscanon.com> - 2012-06-03 21:17 -0700
          Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 07:56 +0200
          Re: Holy boop: goto for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-06-04 04:28 -0300
            Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 00:37 -0700
              Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 07:43 -0700
                Re: Holy boop: goto for Java "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-04 07:47 -0700
                  Re: Holy boop: goto for Java "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-04 08:17 -0700
              Re: Holy boop: goto for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-06-04 17:07 -0300
                Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 13:17 -0700
                  Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-04 14:46 -0700
                    Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-05 07:31 +0200
                      Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-05 09:15 -0700
                        Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-05 10:51 -0700
                          Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-05 10:54 -0700
                          Re: Holy boop: goto for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-06-06 05:58 -0300
                            Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-06 12:11 -0700
                        Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-05 23:24 +0200
                          Re: Holy boop: goto for Java Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-05 17:30 -0400
                            Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-05 20:06 -0700
              Re: Holy boop: goto for Java Patricia Shanahan <pats@acm.org> - 2012-07-22 06:37 -0700
                Re: Holy boop: goto for Java Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2012-07-23 13:27 -0500
                  Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-07-23 13:23 -0700
            Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-04 09:33 -0700
          Re: Holy boop: goto for Java Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-06-04 07:26 -0400
          Re: Holy boop: goto for Java "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-04 07:44 -0700
            Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 18:13 +0200
              Re: Holy boop: goto for Java Gene Wirchenko <genew@ocis.net> - 2012-06-04 10:23 -0700
                Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-04 10:45 -0700
                  Re: Holy boop: goto for Java Robert Klemme <shortcutter@googlemail.com> - 2012-06-04 20:31 +0200
                  Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 11:52 -0700
                    Re: Holy boop: goto for Java Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-04 14:15 -0500
                    Re: Holy boop: goto for Java Lew <lewbloch@gmail.com> - 2012-06-04 14:52 -0700
            Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 10:50 -0700
            Re: Holy boop: goto for Java Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-04 10:56 -0700
            Re: Holy boop: goto for Java Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-04 13:05 -0500
      Re: Holy boop: goto for Java Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-06-04 07:28 -0400
    Re: Holy boop: goto for Java Roedy Green <see_website@mindprod.com.invalid> - 2012-06-03 22:10 -0700

Page 2 of 2 — ← Prev page 1 [2]

#15081

On 6/5/2012 5:24 PM, Robert Klemme wrote:
> On 05.06.2012 18:15, Gene Wirchenko wrote:
>> On Tue, 05 Jun 2012 07:31:44 +0200, Robert Klemme
>> <shortcutter@googlemail.com> wrote:
>
>> Which is often us so being nice to the maintenance programmer is
>> being nice to oneself.
>
> That's a nice side effect - and a motivating argument which helps the
> selfish. :-)
>
>> Besides the story paradigm, I also think in terms of program
>> usefulness. If a program is not very useful, one can write it pretty
>> much any way one wants as the program is going to get tossed anyway.
>> If it is useful, then it is going to stick around, and requirements
>> have a way of changing so the program had better be maintainable. It
>> can also be difficult to tell whether a program will be useful so why
>> not just write them all clearly?
>
> I suspect often the answer to that question is: because the author did
> not understand the problem or the program or programming itself clearly.
> The other big reason is carelessness, often increased by tight
> schedules. Deadlines seem to make people nervous and trying to take
> short circuits. But it will cost - sooner or later.

     In my experience, it is often the case that shortcuts extract
their price sooner rather than later, in the form of more testing
and debugging time (and if you don't pay that price, you pay the
still higher price of more and nastier bugs, more support headaches,
and more patch releases).

     Not always, mind, but often.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15082

On Tue, 05 Jun 2012 17:30:57 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 6/5/2012 5:24 PM, Robert Klemme wrote:
>> On 05.06.2012 18:15, Gene Wirchenko wrote:
>>> On Tue, 05 Jun 2012 07:31:44 +0200, Robert Klemme
>>> <shortcutter@googlemail.com> wrote:
>>
>>> Which is often us so being nice to the maintenance programmer is
>>> being nice to oneself.
>>
>> That's a nice side effect - and a motivating argument which helps the
>> selfish. :-)

     Enlightened selfishness.

>>> Besides the story paradigm, I also think in terms of program
>>> usefulness. If a program is not very useful, one can write it pretty
>>> much any way one wants as the program is going to get tossed anyway.
>>> If it is useful, then it is going to stick around, and requirements
>>> have a way of changing so the program had better be maintainable. It
>>> can also be difficult to tell whether a program will be useful so why
>>> not just write them all clearly?
>>
>> I suspect often the answer to that question is: because the author did
>> not understand the problem or the program or programming itself clearly.

     I would go with the latter but not the former.  One can still
program clearly even if one is unsure of exactly what to do, but those
who can not program are very good at messing up.

>> The other big reason is carelessness, often increased by tight
>> schedules. Deadlines seem to make people nervous and trying to take
>> short circuits. But it will cost - sooner or later.

     Yup.

>     In my experience, it is often the case that shortcuts extract
>their price sooner rather than later, in the form of more testing
>and debugging time (and if you don't pay that price, you pay the
>still higher price of more and nastier bugs, more support headaches,
>and more patch releases).
>
>     Not always, mind, but often.

     Not always, so those who want to justify shortcuts can do so. Try
pointing out that the same arguments apply to playing Russian
roulette, and invite them to play.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#16216

On 6/4/2012 12:37 AM, Robert Klemme wrote:
> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>> What amazes me is that these individuals support this religious
>> stance by arguing that it improves readability, when producing
>> little auxiliary methods usually does anything but.
>
> I am not religious about break / continue (although I use it
> extremely seldom, I am more likely to use "return" inside a loop).
> But I disagree about your general statement about little auxiliary
> methods usually not improving readability.  It all depends on the
> specific case, of course, but giving a short part of an algorithm a
> name (with the option to have a place to put JavaDoc) often helps
> readability in my experience.


One test that I use in this sort of situation is to try to think of a
name for the potential extracted method. If there is a good, clear,
simple name, I make a method. If not, I'm more likely to leave it in place.

Patricia

[toc] | [prev] | [next] | [standalone]

#16252

On 7/22/2012 8:37 AM, Patricia Shanahan wrote:
> On 6/4/2012 12:37 AM, Robert Klemme wrote:
>> On Monday, June 4, 2012 9:28:13 AM UTC+2, Arved Sandstrom wrote:
>>> What amazes me is that these individuals support this religious
>>> stance by arguing that it improves readability, when producing
>>> little auxiliary methods usually does anything but.
>>
>> I am not religious about break / continue (although I use it
>> extremely seldom, I am more likely to use "return" inside a loop).
>> But I disagree about your general statement about little auxiliary
>> methods usually not improving readability.  It all depends on the
>> specific case, of course, but giving a short part of an algorithm a
>> name (with the option to have a place to put JavaDoc) often helps
>> readability in my experience.
>
>
> One test that I use in this sort of situation is to try to think of a
> name for the potential extracted method. If there is a good, clear,
> simple name, I make a method. If not, I'm more likely to leave it in place.
>
> Patricia

I've always liked the way someone long ago put it on this group or maybe 
comp.lang.lisp: "You should define a function if the call to it is 
clearer than the code it replaces."

[toc] | [prev] | [next] | [standalone]

#16263

On Mon, 23 Jul 2012 13:27:27 -0500, Chris Riesbeck
<Chris.Riesbeck@gmail.com> wrote:

>On 7/22/2012 8:37 AM, Patricia Shanahan wrote:

[snip]

>> One test that I use in this sort of situation is to try to think of a
>> name for the potential extracted method. If there is a good, clear,
>> simple name, I make a method. If not, I'm more likely to leave it in place.

     That is the first test.  If there is no GCS name, either it does
not need extracting or you have a bad design that should be addressed.

>I've always liked the way someone long ago put it on this group or maybe 
>comp.lang.lisp: "You should define a function if the call to it is 
>clearer than the code it replaces."

     I would add that if the code is repeated, then break it out even
if it is a bit more complicated.  (I do not like cut-and-paste
programming.)

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15050

Arved Sandstrom wrote:
> In any case, Lew, I don't see that this has much to do with "blessed for 
> OO". We're talking imperative coding here, which is what Java 
> programmers spend the majority of their time doing.

That was rather my point. I should have remembered to include a smiley with that comment.

Java culture rests on the axiom that Java is an object-oriented language.  So if something is built into the language, a circular (and therefore obviously flawed) argument would encourage the sort of foolish remark I made. Examining the foolishness leads to exactly what you said.

So, belatedly, :-)

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15036

On 6/4/2012 12:17 AM, Lew wrote:
> I have never seen a use of Java's labeled 'break' or 'continue' outside
> of tutorials and examples, though.

If you translate some of the examples in Knuth's retort "The use of GOTO 
in structured programming" to Java, you'd find yourself using labeled 
break/continue. I've used it a fair amount in nested loops.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#15039

Lew wrote:
> I have never seen a use of Java's labeled 'break' or 'continue'
> outside of tutorials and examples, though.
>
I've very occasionally found them useful, but they are on the list of things 
I wouldn't miss if they were gone.  Others:

* Do-while.  It seems almost never to be what's needed.  Though I do quite 
often need

  while(true)
  {
   stuff
    if (condition)
    {
      break;
    }
    more stuff
  }

* Local classes (i.e. named classes defined inside a method)
* The non-short-circuit logical operators & and | 

[toc] | [prev] | [next] | [standalone]

#15049

On 04.06.2012 16:44, Mike Schilling wrote:
> Lew wrote:
>> I have never seen a use of Java's labeled 'break' or 'continue'
>> outside of tutorials and examples, though.
>>
> I've very occasionally found them useful, but they are on the list of things
> I wouldn't miss if they were gone.  Others:
>
> * Do-while.  It seems almost never to be what's needed.  Though I do quite
> often need
>
>    while(true)
>    {
>     stuff
>      if (condition)
>      {
>        break;
>      }
>      more stuff
>    }

Interesting: I cannot remember having needed this.  While I do remember 
using do {} while.  What use cases do you have for the construct above?

> * Local classes (i.e. named classes defined inside a method)

+1

> * The non-short-circuit logical operators&  and |

+1

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15051

On Mon, 04 Jun 2012 18:13:00 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 04.06.2012 16:44, Mike Schilling wrote:
>> Lew wrote:
>>> I have never seen a use of Java's labeled 'break' or 'continue'
>>> outside of tutorials and examples, though.
>>>
>> I've very occasionally found them useful, but they are on the list of things
>> I wouldn't miss if they were gone.  Others:
>>
>> * Do-while.  It seems almost never to be what's needed.  Though I do quite
>> often need
>>
>>    while(true)
>>    {
>>     stuff
>>      if (condition)
>>      {
>>        break;
>>      }
>>      more stuff
>>    }
>
>Interesting: I cannot remember having needed this.  While I do remember 
>using do {} while.  What use cases do you have for the construct above?

     In the sense that there are other ways one can do this, no, you
do not need this.  It can be useful if you have multiple tests in that
loop, especially multiple tests that cannot be combined.  An example
of this would be a body of:
          process first piece
          if error
             break or continue as needed
          process middle piece
          if error
             break or continue as needed
          process last piece

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15053

Gene Wirchenko wrote:
> Robert Klemme wrote:
>> Mike Schilling wrote:
>>> * Do-while.  It seems almost never to be what's needed.  Though I do quite
>>> often need
>>>
>>>    while(true)
>>>    {
>>>     stuff
>>>      if (condition)
>>>      {
>>>        break;
>>>      }
>>>      more stuff
>>>    }
>>
>> Interesting: I cannot remember having needed this.  While I do remember 
>> using do {} while.  What use cases do you have for the construct above?
> 
>      In the sense that there are other ways one can do this, no, you
> do not need this.  It can be useful if you have multiple tests in that
> loop, especially multiple tests that cannot be combined.  An example
> of this would be a body of:
>           process first piece
>           if error
>              break or continue as needed
>           process middle piece
>           if error
>              break or continue as needed
>           process last piece
> 
> [snip]

public void processResources(String ... resourceNames)
{
  for (String name : resourceNames)
  {
    BufferedReader br;
    try 
    {
      br = new BufferedReader(new FileReader(name));
    }
    catch(FileNotFoundException exc)
    {
      logger.error("Cannot find "+ name, exc);
      continue;
    }
    assert br != null; // and is valid
    try
    {
      doSomething(br);
    }
    finally
    {
      try
      {
        br.close();
      }
      catch(IOException exc)
      {
        logger.error("Cannot close "+ name, exc);
        continue;
      }
    }
    reportComplete(name);
  }
}

(Not using try-with-resources here, in order to illustrate the idiom.)

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15057

On 04.06.2012 19:45, Lew wrote:
> public void processResources(String ... resourceNames)
> {
...

I'd rather

public void processResources(String ... resourceNames)
{
   for (String name : resourceNames)
   {
     try
     {
       final BufferedReader br =
         new BufferedReader(new FileReader(name));
       try
       {
         doSomething(br);
         reportComplete(name);
       }
       catch(IOException exc)
       {
         logger.error("Issue while processing "+ name, exc);
       }
       finally
       {
         close(br);
       }
     }
     catch(FileNotFoundException exc)
     {
       logger.error("Cannot find "+ name, exc);
     }
   }
}

close() is a static helper method which catches IOException and reports it.

In other words, I try to place the catch block at the end of a logical 
section and use try catch to only execute some commands in absence of 
error.  The exception will make the continue superfluous.  The advantage 
in my eyes is that you can easily follow the regular flow and have error 
handling concentrated in one place.  I sometimes even refactor out 
methods so I can have this catch at the end idiom.

In a more realistic example I'd probably extract parts of this into a 
method (likely the inner try catch finally).

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15058

On 6/4/12 10:45 AM, Lew wrote:
> Gene Wirchenko wrote:
>> Robert Klemme wrote:
>>> Mike Schilling wrote:
>>>> * Do-while.  It seems almost never to be what's needed.  Though I do quite
>>>> often need
>>>>
>>>>     while(true)
>>>>     {
>>>>      stuff
>>>>       if (condition)
>>>>       {
>>>>         break;
>>>>       }
>>>>       more stuff
>>>>     }
>>>
>>> Interesting: I cannot remember having needed this.  While I do remember
>>> using do {} while.  What use cases do you have for the construct above?
>>
>>       In the sense that there are other ways one can do this, no, you
>> do not need this.  It can be useful if you have multiple tests in that
>> loop, especially multiple tests that cannot be combined.  An example
>> of this would be a body of:
>>            process first piece
>>            if error
>>               break or continue as needed
>>            process middle piece
>>            if error
>>               break or continue as needed
>>            process last piece
>>
>> [snip]
>
> public void processResources(String ... resourceNames)
> {
>    for (String name : resourceNames)
>    {
>      BufferedReader br;
>      try
>      {
>        br = new BufferedReader(new FileReader(name));
FWIW, this is a potential resource leak (think OOM on the "new 
BufferedReader")
>      }
>      catch(FileNotFoundException exc)
>      {
>        logger.error("Cannot find "+ name, exc);
>        continue;
>      }
>      assert br != null; // and is valid
br is never assigned null, you could make br final.  I think it *should* 
be final.

>      try
>      {
>        doSomething(br);
>      }
>      finally
>      {
>        try
>        {
>          br.close();
>        }
>        catch(IOException exc)
>        {
>          logger.error("Cannot close "+ name, exc);
>          continue;
>        }
>      }
>      reportComplete(name);
>    }
> }
>
> (Not using try-with-resources here, in order to illustrate the idiom.)
>

Hmm, a failure to close causes a resource processing not to be complete?

[toc] | [prev] | [next] | [standalone]

#15060

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:

> FWIW, this is a potential resource leak (think OOM on the "new 
> BufferedReader")

In the same sense that the loud BANG from a handgrenade is a 
health-and-safety hazard: if one goes off next to your ear you 
might go deaf.

If you get an OutOfMemory exception on the "new BufferedReader"
bit, you're already fubar and a dangling file-handle more or 
less isn't going to affect the situation any.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#15065

Daniel Pitts wrote:
> Lew wrote:
>> public void processResources(String ... resourceNames)
>> {
>>    for (String name : resourceNames)
>>    {
>>      BufferedReader br;
>>      try
>>      {
>>        br = new BufferedReader(new FileReader(name));

> FWIW, this is a potential resource leak (think OOM on the "new 
> BufferedReader")

OOM is not a resource leak, it's a program crash.

I generally don't handle 'Error's. (Except when I do.) 
If the OOM happens here as you suggest, well, what Leif said.

> >      }
> >      catch(FileNotFoundException exc)
> >      {
> >        logger.error("Cannot find "+ name, exc);
> >        continue;
> >      }
> >      assert br != null; // and is valid

> br is never assigned null, you could make br final.  I think it *should* 
> be final.

Yes. Actually, in real code with this idiom I do make it final. Good catch.

> >      try
> >      {
> >        doSomething(br);
> >      }
> >      finally
> >      {
> >        try
> >        {
> >          br.close();
> >        }
> >        catch(IOException exc)
> >        {
> >          logger.error("Cannot close "+ name, exc);
> >          continue;
> >        }
> >      }
> >      reportComplete(name);
> >    }
> > }
> >
> > (Not using try-with-resources here, in order to illustrate the idiom.)
> >
> 
> Hmm, a failure to close causes a resource processing not to be complete?

You read too much into the method names.

It's a pattern. I do not claim the names and all are useful in real life, only for pedagogy.

Use better names if these make you twitch.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15054

On 6/4/12 7:44 AM, Mike Schilling wrote:
> Lew wrote:
>> I have never seen a use of Java's labeled 'break' or 'continue'
>> outside of tutorials and examples, though.
>>
> I've very occasionally found them useful, but they are on the list of things
> I wouldn't miss if they were gone.  Others:
>
> * Do-while.  It seems almost never to be what's needed.  Though I do quite
> often need
>
>    while(true)
>    {
>     stuff
>      if (condition)
>      {
>        break;
>      }
>      more stuff
>    }
>
> * Local classes (i.e. named classes defined inside a method)
> * The non-short-circuit logical operators&  and |
>
>

I've seen that loop refactored to:

stuff();
while (!condition) {
   moreStuff();
   stuff();
}


Or:

for (stuff(); !condition; stuff() {
   moreStuff();
}


Not saying that is better, just saying I've seen it.

[toc] | [prev] | [next] | [standalone]

#15055

On 6/4/12 7:44 AM, Mike Schilling wrote:
> Lew wrote:
>> I have never seen a use of Java's labeled 'break' or 'continue'
>> outside of tutorials and examples, though.
>>
> I've very occasionally found them useful, but they are on the list of things
> I wouldn't miss if they were gone.  Others:
[snip]
> * Local classes (i.e. named classes defined inside a method)
Holy unknown construct Batman!  I had no idea this was possible, and I 
definitely would have used in in certain places!

Specifically, for callbacks where I need to set values to be retrieved 
after the call.


void doSomething(SomethingSomething something) {
   class MyCallback implements SomeCallbackInterface {
     int calls;
     boolean error;


     public void somethingCalled() { ++calls; }
     public void somethingErrored() { error = true; }
   }

    MyCallback cb = new MyCallback();

    something.doSomethingwith(cb);
    if (error) {
       handleError();
    }
    if (cb.calls < 100) { smallBatch(); } else { largeBatch(); }
}


For example.

I have often instead created private static inner classes for this 
purpose, but that pollutes the class IMO.

[toc] | [prev] | [next] | [standalone]

#15056

Mike Schilling <mscottschilling@hotmail.com> wrote:
>
> * The non-short-circuit logical operators & and | 

There's an argument that we should prefer the 
non-short-circuit versions (of course, only where
performance or program logic doesn't dictate the 
short-circuit operators) as this reduces the number
of paths in the code and makes the program behaviour
more consistent (particularly in time) which helps 
with debugging.

Of course, for Java I think that ship has sailed. The use
of the non-short-circuit operators is so rare that to use
them is to ask for your code to be misinterpreted by 
others.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#15037

On 6/3/2012 11:03 PM, Daniel Pitts wrote:
> On 6/3/12 7:36 PM, markspace wrote:
>> Just looking for an extended answer to an earlier question (strings in a
>> case-switch statement), I found this on Joe Darcy's blog:
>>
>> "Summary
>>
>> "Provide the benefits of the time-testing goto control structure to Java
>> programs. The Java language has a history of adding new control
>> structures over time, the assert statement in 1.4, the enhanced for-loop
>> in 1.5,and try-with-resources in 7. Having support for goto is
>> long-overdue and simple to implement since the JVM already has goto
>> instructions."
>>
>> <https://blogs.oracle.com/darcy/entry/upcoming_jep>
>>
>> Holy booping bat boop Batman!
>>
> Check the date of that article before getting to excited/disappointed ;-)

When I first saw that article, I got as far as posting it in an IRC 
channel [without context] before I realized it was an joke. Fortunately, 
I realized the joke before any discussion started up around it :-P .

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#15031

On Sun, 03 Jun 2012 19:36:53 -0700, markspace <-@.> wrote, quoted or
indirectly quoted someone who said :

>"Provide the benefits of the time-testing goto control structure to Java 
>programs. 

People take a rule of thumb and turn it into a commandment from a
vicious god.

I remember back in the early 90s  in C  demonstrating how a common
pattern could be implemented with a goto. The boss insisted on a
goto-less implementation that was many times more verbose.  NORMALLY
GoTos make for more tangled code. This time it did not.

Parser generators are simpler if they can generate gotos. Nobody is
supposed to even look at the code.

As a general rule, you don't want them. A team leader would want
members to get permission to use one.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web