«

"Randolf Richardson" <kingpin+> writes:

> 1. The ability to share code between methods within a class,
> which all end with the same functionality (this could be more
> efficient than calling another method; javac would need to generate
> errors such as attempts to access variables that belong to different
> methods, return type mismatches, etc.)

That's headache-inducing and makes the code far less readable (thus it
runs counter to your item 0). Why do you think the MINISCULE overhead
in a local method call is worth the MAJOR hassle of having to look in
so many places to follow the flow of a method? Not to mention that you
still would only be able to goto code that completes with a return,
and the label's method would need to have the same return type and
with a compatible throws clause, and the class file spec would need to
add a global label table...

Refactor the shared code into a private final method and trust the
runtime to inline the code as necessary. Or wait for closures to be
implemented.

Randolf Richardson wrote:
> This typically occurs because the reserved word "goto" isn't
> implemented. There are situations where "goto" would be very useful,
> such as:
>
I totally disagree. Assemblers need "goto" but no decent HLL does. That
goes for COBOL too and before you ask, yes I've written GOTO-less COBOL.
I have never used goto (or needed it) in C and see no need for it in Java.

> 0. An alternative to "break label" since label is currently
> limited in where it can be located (such code could be easier to read)
>
I don't use this construction in C either and, again, don't need it.

> 1. The ability to share code between methods within a class,
> which all end with the same functionality (this could be more efficient
> than calling another method; javac would need to generate errors such as
> attempts to access variables that belong to different methods, return
> type mismatches, etc.)
>
Encapsulating the code in a private method makes for more readable code
as well as eliminating code duplication.

> I do agree with your view that infinite loops that depend on
> exceptions are a bad practice. Using conditionals to trigger a "break"
> would also be better handled by making that the focus of the loop -- and
> if they need to compare afterwards, then "do { ... } while (condition);"
> can certainly solve that problem.
>
Yes - but that's a result of classes that throw exceptions when their
methods would be better off returning control values. IMO if you have to
use exceptions to control normal logic flow in code that calls the class
methods merely demonstrates bad class design.

I never design classes/methods that force their user to control normal
logic flow with exceptions: I use methods that return control
information (e.g hasNextObject() to control loops). Similarly, my
constructors never throw exceptions: code that may signal errors with
exceptions is pulled out of the constructor and encapsulated as a
separate method. This is because try...catch blocks that include class
instance declarations screw up otherwise clean block structures by
preventing me from grouping all object instance declarations at the
start of a block rather than sprinkling them through the code.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On 02.02.2007 16:14, Lew wrote:

> Just a suggestion designed to help you.

Adding to that: a meaningful subject also often helps.

Cheers

robert

Randolf Richardson wrote:
> On Wed, 31 Jan 2007 04:55:35 -0800, Lew <> wrote:
>> wrote:
> [sNip]
>>> while (true) {
>>
>> To depend on exceptions as flow control is a bad practice.
> [sNip]
>
> This typically occurs because the reserved word "goto" isn't
> implemented. There are situations where "goto" would be very useful,
> such as:
>
> 0. An alternative to "break label" since label is currently
> limited in where it can be located (such code could be easier to read)
>
> 1. The ability to share code between methods within a class,
> which all end with the same functionality (this could be more efficient
> than calling another method; javac would need to generate errors such as
> attempts to access variables that belong to different methods, return
> type mismatches, etc.)

I disagree, I think goto was dumped for very good reasons, and
structured programming (i.e. no gotos; use methods and refactoring
techniques instead) makes a lot more sense.

>
> I do agree with your view that infinite loops that depend on
> exceptions are a bad practice. Using conditionals to trigger a "break"
> would also be better handled by making that the focus of the loop -- and
> if they need to compare afterwards, then "do { ... } while (condition);"
> can certainly solve that problem.
>
> --Randolf Richardson - kingpin+
> The Lumber Cartel, local 42 (Canadian branch)
> http://www.lumbercartel.ca/

On 03.02.2007 13:22, Martin Gregorie wrote:
> Randolf Richardson wrote:

Completely agree, Martin. "Goto" is quite nonsense - it's not needed
from a theoretical as well as from a practical point of view.

>> 1. The ability to share code between methods within a class,
>> which all end with the same functionality (this could be more
>> efficient than calling another method; javac would need to generate
>> errors such as attempts to access variables that belong to different
>> methods, return type mismatches, etc.)
>>
> Encapsulating the code in a private method makes for more readable code
> as well as eliminating code duplication.

Plus, with modern JVM's the private method is typically inlined *if* it
is a performance bottleneck. If not, it's not worth bothering about the
method invocation overhead anyway.

Side note: I am amazed that the "issue" of "goto" keeps popping up. The
high time of Basic has long since gone but people still seem to cling to
this ancient concept. Or do all these folks use assembler during their
daily work?

Regards

robert

Martin Gregorie wrote:
> This is because try...catch blocks that include class
> instance declarations screw up otherwise clean block structures by
> preventing me from grouping all object instance declarations at the
> start of a block rather than sprinkling them through the code.

Personally I prefer to declare variables closest to the point of use, rather
than all at the beginning of a block.

- Lew

Alex Hunsley wrote:
> I disagree, I think goto was dumped for very good reasons, and
> structured programming (i.e. no gotos; use methods and refactoring
> techniques instead) makes a lot more sense.

I suspect that Java left in "goto" as a reserved word for the same
reason that Ada supports (with intentionally hideous syntax) "goto" --
considerations of machine-generated code.

But jumping from one method to another? Ye gods! Even Fortran doesn't
allow that, except for a jump-out-to-caller mechanism that is
essentially a poor-man's "throw".

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

On Sun, 04 Feb 2007 03:24:44 -0800, Robert Klemme
<> wrote:
> On 03.02.2007 13:22, Martin Gregorie wrote:
>> Randolf Richardson wrote:
>
> Completely agree, Martin. "Goto" is quite nonsense - it's not needed
> from a theoretical as well as from a practical point of view.
>
>>> 1. The ability to share code between methods within a class,
>>> which all end with the same functionality (this could be more
>>> efficient than calling another method; javac would need to generate
>>> errors such as attempts to access variables that belong to different
>>> methods, return type mismatches, etc.)
>>
>> Encapsulating the code in a private method makes for more readable code
>> as well as eliminating code duplication.
>
> Plus, with modern JVM's the private method is typically inlined *if* it
> is a performance bottleneck. If not, it's not worth bothering about the
> method invocation overhead anyway.

That's a perfectly valid alternative for one particular application of
"goto."

> Side note: I am amazed that the "issue" of "goto" keeps popping up. The
> high time of Basic has long since gone but people still seem to cling to
> this ancient concept. Or do all these folks use assembler during their
> daily work?

This discussion is very interesting. One of the reasons I think "goto"
keeps coming up is that there is demand for it. Although it is commonly
associated with BASIC, it's also available in other languages such as Perl
(which can be written in a procedural or OO style, or as mixture of both),
assembler (the instruction is usually called "jmp"), etc.

I'm not convinced that "goto" is a bad thing, especially given the
numerous "while (true) { ... }" loops that I've seen over the years
(granted, those are usually examples of bad coding style, but many people
use it because they don't have "goto" at their disposal).

To me, the limit on the placement of labels at the beginning of a loop,
followed by a partial "goto" using the "break label;" instruction is
actually more difficult to follow because first one has to find the label
in preceeding code, then search for the end of the loop to follow the
program flow from there. If the label could at least be placed anywhere
from the beginning of the loop to immediately after its end, with "goto"
enabled for this, I do think this could actually make things a bit better.

I definitely don't agree that removing "goto" eliminates "spaghetti code"
and works against the OO concept (as someone pointed out in a separate
reply), rather it's the individual developers who will continue to write
terrible code even without "goto" (which seems to happen now). As an
aside, a much more serious problem is the lack of source code comments
(usually the majority of the comments in source code are a copy of the GPL
or some other license agreement -- the slightly better programmers include
a minor smattering of vague hints in what seem to be fewer than one or two
dozen randomly selected lines {out of thousands}).

I do believe that a good developer can use "goto" in an intelligent way
that doesn't result in "spaghetti code" and doesn't detract from the OO
concept, so perhaps if Sun ever does decide to implement it they could
also require a "javac" command-line option like
"-allowadvancedinstructions:goto" as a hint that alternatives are strongly
encouraged.

The masses seem to be convinced that "goto" is bad, but in the history of
the world there are countless examples where the masses were wrong (e.g.,
political elections, setting women on fire to determine if they were
witches, removing tonsils because medical experts at the time believed
them to be useless, mis-treatment of leppers, etc.).

--
Randolf Richardson - kingpin+
The Lumber Cartel, local 42 (Canadian branch)
http://www.lumbercartel.ca/

Lew wrote:
> Martin Gregorie wrote:
>> This is because try...catch blocks that include class instance
>> declarations screw up otherwise clean block structures by preventing
>> me from grouping all object instance declarations at the start of a
>> block rather than sprinkling them through the code.
>
> Personally I prefer to declare variables closest to the point of use,
> rather than all at the beginning of a block.
>
Yes, I know your preference is normal and widely used.

That was a personal opinion intended to show why I don't like
constructors that throw exceptions. I've written far too much C (and
Algol 60, Algol 68R, PL/9 and PL/1) to easily let go of the habit of
declaring variables at the start of a block. If that makes me weird, so
be it.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On 05.02.2007 09:34, Randolf Richardson wrote:
> This discussion is very interesting. One of the reasons I think
> "goto" keeps coming up is that there is demand for it.

I'm guessing that the demand is rather low - compared with the demand
for other things (including fixing bugs).

> I'm not convinced that "goto" is a bad thing, especially given the
> numerous "while (true) { ... }" loops that I've seen over the years
> (granted, those are usually examples of bad coding style, but many
> people use it because they don't have "goto" at their disposal).

An endless loop with "while(true)" is at least as good as a loop with
"goto".

> To me, the limit on the placement of labels at the beginning of a
> loop, followed by a partial "goto" using the "break label;" instruction
> is actually more difficult to follow because first one has to find the
> label in preceeding code, then search for the end of the loop to follow
> the program flow from there. If the label could at least be placed
> anywhere from the beginning of the loop to immediately after its end,
> with "goto" enabled for this, I do think this could actually make things
> a bit better.

We must have very different coding styles. I cannot remember ever
having used a label in Java. I simply don't need them.

> I definitely don't agree that removing "goto" eliminates "spaghetti
> code" and works against the OO concept (as someone pointed out in a
> separate reply), rather it's the individual developers who will continue
> to write terrible code even without "goto" (which seems to happen now).

You are right. But this does not make an argument for introducing
"goto" in Java. Only if benefits outweigh costs of this change it's
reasonable to do it. And I don't see that.

> The masses seem to be convinced that "goto" is bad, but in the
> history of the world there are countless examples where the masses were
> wrong (e.g., political elections, setting women on fire to determine if
> they were witches, removing tonsils because medical experts at the time
> believed them to be useless, mis-treatment of leppers, etc.).

I won't follow this train of discussion as there are numerous things
that could be said to this. Just this: if the majority of people do not
care to have "goto" in Java then Sun's efforts are spent far better in
realizing other features or fixing bugs. This alone is reason enough
for not doing it IMHO.

Regards

robert