2 extends

java-programmer, 2 extends Dale King wrote:
> The Wogster wrote:
>
>> Thomas G. Marshall wrote:
>>
>>> The Wogster coughed up:
>>>
>>>> Irlan agous wrote:
>>>>
>>>> It's like the goto, it's legal in C, but the only times I have seen it
>>>> used, were because someone had programmed themselves into a corner.
>
>
> In C there were some cases where it was necessary/mad the code clearer.
> Most of those cases in Java have other constructs that eliminate the
> need for an arbitrary goto. Exceptions, labelled break and continue
> eliminate most of the cases for goto from C. But since C doesn't have
> those you are forced to use goto or over complicate the code.
>
>> With languages that have richly designed looping and redirection
>> constructs, you shouldn't need the goto. I didn't say it was always
>> to be avoided, just that when you feel the need to use goto (except
>> maybe in Gee Whiz Basic), it's usually a pretty good indicator that
>> the code design is lacking.
>
>
> That design as you said could be the design of the language and not
> necessarily the design of the program. Or are you one of those anti-goto
> that also disagrees with goto-like constructs like break, continue, and
> exceptions?

Uh no, because those leave control with the language. Most people who
defend the goto so vehemently,are, with modern languages like Java,
simply are using it to emulate something else available within the language.

Let's see, in the last 10 years, I have written about 1,000,000 lines of
C code, the number of actual goto's in there, none. During that time, I
viewed probably 40,000,000 more lines, which contained maybe 20 gotos.
Shows how little goto is actually needed. Of those 5, were code that
was complex trying to do something simple, usually the reason I was
looking at it, was because it wasn't working (poor design). Five more
were instances where you had the jack-of-all-procedures, where the
programmer had written a bunch of procedures in one block of code (again
poor design). They used goto to make the thing work. The remaining
ones, were places where the programmer had written themselves into a
corner, and under pressure of getting the thing to work, used goto to
bail out (again poor design).

W

java-programmer >> 2 extends Dale King wrote:
> The Wogster wrote:
>
>> Thomas G. Marshall wrote:
>>
>>> The Wogster coughed up:
>>>
>>>> Irlan agous wrote:
>>>>
>>>> It's like the goto, it's legal in C, but the only times I have seen it
>>>> used, were because someone had programmed themselves into a corner.
>
>
> In C there were some cases where it was necessary/mad the code clearer.
> Most of those cases in Java have other constructs that eliminate the
> need for an arbitrary goto. Exceptions, labelled break and continue
> eliminate most of the cases for goto from C. But since C doesn't have
> those you are forced to use goto or over complicate the code.
>
>> With languages that have richly designed looping and redirection
>> constructs, you shouldn't need the goto. I didn't say it was always
>> to be avoided, just that when you feel the need to use goto (except
>> maybe in Gee Whiz Basic), it's usually a pretty good indicator that
>> the code design is lacking.
>
>
> That design as you said could be the design of the language and not
> necessarily the design of the program. Or are you one of those anti-goto
> that also disagrees with goto-like constructs like break, continue, and
> exceptions?

Uh no, because those leave control with the language. Most people who
defend the goto so vehemently,are, with modern languages like Java,
simply are using it to emulate something else available within the language.

Let's see, in the last 10 years, I have written about 1,000,000 lines of
C code, the number of actual goto's in there, none. During that time, I
viewed probably 40,000,000 more lines, which contained maybe 20 gotos.
Shows how little goto is actually needed. Of those 5, were code that
was complex trying to do something simple, usually the reason I was
looking at it, was because it wasn't working (poor design). Five more
were instances where you had the jack-of-all-procedures, where the
programmer had written a bunch of procedures in one block of code (again
poor design). They used goto to make the thing work. The remaining
ones, were places where the programmer had written themselves into a
corner, and under pressure of getting the thing to work, used goto to
bail out (again poor design).

W

java-programmer >> 2 extends Thomas G. Marshall wrote:
> The Wogster coughed up:
>
>>Thomas G. Marshall wrote:
>>
>>>The Wogster coughed up:
>>>
>>>
>>>>Thomas G. Marshall wrote:
>>>>
>>>>
>>>>>The Wogster coughed up:
>>>
>>>
>>>...[rip]...
>>>
>>>[regarding goto]...
>>>
>>>
>>>>>>Procedural program design theories don't require it, and OOP
>>>>>>should have made it illegal (IMNSHO).
>>>>>
>>>>>It has nothing whatsoever to do with either discipline
>>>>>specifically, so such a statement doesn't accomplish much. {shrug}
>>>>
>>>>I maintain that when you "need" goto, it's usually in a function or
>>>>method that is trying to do too many things, and that breaking it
>>>>down into smaller pieces will actually lead to a cleaner, more
>>>>maintainable construct that doesn't need the goto.
>>>
>>>
>>>
>>>A very common use for goto is an exit out of a nested loop in a
>>>language without multilevel or labeled breaks. Would you accept or
>>>not accept that as a perfectly reasonable usage of goto?
>>
>>That would be acceptable, however this is a Java group, and Java does
>>have those capabilities, does it not? Besides that the building of a
>>nested loop that needs you to bail from the very inside, all the way
>>to the outside, is often a design that is far too complicated in the
>>first place.
>>
>>
>>>It is still not at all clear where you wish to draw the line,
>>>particularly with the statement you made:
>>>
>>> "The Wogster":
>>> Procedural program design theories don't
>>> require it, and OOP should have made it
>>> illegal (IMNSHO).
>>>
>>>Here's what's wrong with it:
>>>
>>>1. That procedural or any other program design theories don't require
>>>something is certainly of no issue. Once you have a while()
>>>construct, you do not need the for(;;) loop, and once you have
>>>if/else, you do not need the switch. Would you hence argue against
>>>the for() and switch? It's a pointless statement.
>>>
>>>2. The concepts of OO and procedural programming are entirely
>>>orthogonal to whether or not a language contains a goto. It is
>>>applicable throughout both paradigms, and has no specific impact to
>>>either. Again, the /out-of-hand/ demonizing of goto is thus far without
>>>merit. Demonizing the misuse of goto is certainly with merit, as is
>>>demonizing the misuse of anything, but that is an entirely different
>>>exercise than what you seem to be attempting.
>>>
>>>Now don't get me wrong here: I /prefer/ the restricted goto within
>>>java (downward only "labeled" or "named" break) to the unrestricted
>>>versions found in C/C++, because I like the way the code looks as a
>>>result. But when you have a language without such a downward goto,
>>>then using an unrestricted goto in a careful downward fashion is
>>>perfectly fine, and railing against its usage is outright silly.
>>
>>Whatever go ahead, I don't really care if you want to write lots of
>>gotos, just hope I never have to maintain that code.....
>
>
> I never said I wanted to write "lots of goto's". And if I put them in
> there, then it would be to improve maintainability.
>

As I put in another message, I have written a lot of code, and worked
with considerably more, still haven't found an instance where goto made
things more maintainable. Every goto I have seen, since my days in
assembler, was as a result of someone trying to make sense of code that
was poorly (if at all) designed.

We may need to agree to disagree on this one, though, were arguing in
circles now....

W

java-programmer >> 2 extends The Wogster coughed up:
> Thomas G. Marshall wrote:
>> The Wogster coughed up:

...[rip]...

>>> Whatever go ahead, I don't really care if you want to write lots of
>>> gotos, just hope I never have to maintain that code.....
>>
>>
>> I never said I wanted to write "lots of goto's". And if I put them
>> in there, then it would be to improve maintainability.
>>
>
> As I put in another message, I have written a lot of code, and worked
> with considerably more, still haven't found an instance where goto
> made things more maintainable. Every goto I have seen, since my days
> in assembler, was as a result of someone trying to make sense of code
> that was poorly (if at all) designed.
>
> We may need to agree to disagree on this one, though, were arguing in
> circles now....

Probably a good idea, and you should understand that I do not wish to be
contentious nor offend. But I still am struggling to understand your
position. IYO, let's forget the "what I've seen is", and let's concentrate
on "what bothers me", if it's ok with you, to establish your stake in the
sand.

Take a look at the following in a goto-enabled language:

for (int z = 0; z < 10; z++)
for (int y = 0; y < 10; y++)
for (int x = 0; x < 10; x++)
if (array[z][y][x] == somethingNeeded)
goto hop_out;
hop_out:
(continue on)

Is /this/ something that bothers your sensibilities?

Now let's look at this. Note, this is purposefully not ideal---I'm
searching for lesser-quality scenarios. And note that the "status" is
computed and maintained for proper return---I'm limiting the detail here on
purpose as well:

Send UDP/IP initial contact datagram...
If (abortNak)
goto finish_up;

(UDP transactions here)
if (errorCondition) // or whatever
goto finish_up;

(UDP transactions here)
if (errorCondition or abortNak) // or whatever
goto finish_up;

(UDP transactions)
(etc)

finish_up:
Notify database;
Send UDP trailing datagram...
return status;

Are you at odds here as well?

--
I've seen this a few times--Don't make this mistake:

Dwight: "This thing is wildly available."
Smedly: "Did you mean wildly, or /widely/ ?"
Dwight: "Both!", said while nodding emphatically.

Dwight was exposed to have made a grammatical
error and tries to cover it up by thinking
fast. This is so painfully obvious that he
only succeeds in looking worse.

java-programmer >> 2 extends email***@***.com coughed up:
> "Thomas G. Marshall"
> <email***@***.com> wrote in
> message news:<yeMqe.269$qr1.189@trndny07>...
>> The Wogster coughed up:
>
> <Snwwip.>
>
>>
>> The cases I'm thinking of almost always involved a function where
>> the exit of the function required several things to happen. The
>> goto was in these cases a much clearer alternative to otherwise
>> *horrible* contrivances. In these cases, to say that this was done
>> only because the author missed a better non-goto way to design it is
>> to imply that using goto is /always/ to be avoided, and is simply
>> incorrect.
>
> Hi, Thomas!
>
> Could you provide this sample of code, or an equivalent?
>
> Just curious,
>
> .ed
>
> www.EdmundKirwan.com - Home of The Fractal Class Composition.

Sure---I think that the examples I pondered in my latest post to The Wogster
should be ok.

--
I've seen this a few times--Don't make this mistake:

Dwight: "This thing is wildly available."
Smedly: "Did you mean wildly, or /widely/ ?"
Dwight: "Both!", said while nodding emphatically.

Dwight was exposed to have made a grammatical
error and tries to cover it up by thinking
fast. This is so painfully obvious that he
only succeeds in looking worse.

java-programmer >> 2 extends Thomas G. Marshall wrote:
> The Wogster coughed up:
>
>>Thomas G. Marshall wrote:
>>
>>>The Wogster coughed up:
>
>
> ...[rip]...
>
>
>>>>Whatever go ahead, I don't really care if you want to write lots of
>>>>gotos, just hope I never have to maintain that code.....
>>>
>>>
>>>I never said I wanted to write "lots of goto's". And if I put them
>>>in there, then it would be to improve maintainability.
>>>
>>
>>As I put in another message, I have written a lot of code, and worked
>>with considerably more, still haven't found an instance where goto
>>made things more maintainable. Every goto I have seen, since my days
>>in assembler, was as a result of someone trying to make sense of code
>>that was poorly (if at all) designed.
>>
>>We may need to agree to disagree on this one, though, were arguing in
>>circles now....
>
>
>
> Probably a good idea, and you should understand that I do not wish to be
> contentious nor offend. But I still am struggling to understand your
> position. IYO, let's forget the "what I've seen is", and let's concentrate
> on "what bothers me", if it's ok with you, to establish your stake in the
> sand.
>
> Take a look at the following in a goto-enabled language:
>
> for (int z = 0; z < 10; z++)
> for (int y = 0; y < 10; y++)
> for (int x = 0; x < 10; x++)
> if (array[z][y][x] == somethingNeeded)
> goto hop_out;
> hop_out:
> (continue on)
>
> Is /this/ something that bothers your sensibilities?
>

Yes, but more that it's a horrible construct, then that it contains a
goto.

Here is another option, that does the same thing, but is, IMNSHO clearer;

bool onlyFirst = true; // only find first somethingNeeded

for (int z = 0; z < 10 && onlyFirst == true; z++)
for (int y = 0; y < 10 && onlyFirst == true; y++)
for (int x = 0; x < 10 && onlyFirst == true; x++)
if (array[z][y][x] == somethingNeeded)
{
onlyFirst == false;
// do other stuff
}

Where the goto becomes a problem, is when do other stuff is 30 lines, so
that the goto is a couple of screens later, and someone not realizing
that the for gets usurped later on, adds code between the "for (int z"
and the "for (int y" that counts on z getting to 10. Of course later
when the code doesn't work the programmer who did it, is unavailable,
and you spend a nice, warm sunny Sunday afternoon, trying to figure out
what happened, instead of tossing a ball around with your kids, before
putting some steaks on the barbie....

My version indicates that there are other conditions, and that z may not
get to 10, and then the programmer would go looking to find out what
happens to onlyFirst.

> Now let's look at this. Note, this is purposefully not ideal---I'm
> searching for lesser-quality scenarios. And note that the "status" is
> computed and maintained for proper return---I'm limiting the detail here on
> purpose as well:
>
> Send UDP/IP initial contact datagram...
> If (abortNak)
> goto finish_up;
>
> (UDP transactions here)
> if (errorCondition) // or whatever
> goto finish_up;
>
> (UDP transactions here)
> if (errorCondition or abortNak) // or whatever
> goto finish_up;
>
> (UDP transactions)
> (etc)
>
> finish_up:
> Notify database;
> Send UDP trailing datagram...
> return status;
>
> Are you at odds here as well?

That is possibly the worst piece of code I have ever seen, and I have
seen some awful stuff in my years. It's an off the cuff example, so
I'll grant you that, how about this version though:

// send initial datagram

while(getData()); // sets abortNak and errorCondition
{
if(!abortNak && !errorCondition)
{
// UDP transactions etc
}
// Notify database;
}

// Send Trailing datagram
// return status

Here is another version of just the if statement:

if(abortNak)
{
// we could do nothing here.
}
elseif (errorCondition)
{
// we could optionally add logging code here
}
else
{
// UDP transactions
}

// Notify database;
// Send Trailing datagram
// return status

W

java-programmer >> 2 extends The Wogster coughed up:
> Thomas G. Marshall wrote:

...[rip]...

>> Take a look at the following in a goto-enabled language:
>>
>> for (int z = 0; z < 10; z++)
>> for (int y = 0; y < 10; y++)
>> for (int x = 0; x < 10; x++)
>> if (array[z][y][x] == somethingNeeded)
>> goto hop_out;
>> hop_out:
>> (continue on)
>>
>> Is /this/ something that bothers your sensibilities?
>>
>
> Yes, but more that it's a horrible construct, then that it contains a
> goto.
>
> Here is another option, that does the same thing, but is, IMNSHO
> clearer;
> bool onlyFirst = true; // only find first somethingNeeded
>
> for (int z = 0; z < 10 && onlyFirst == true; z++)
> for (int y = 0; y < 10 && onlyFirst == true; y++)
> for (int x = 0; x < 10 && onlyFirst == true; x++)
> if (array[z][y][x] == somethingNeeded)
> {
> onlyFirst == false;
> // do other stuff
> }

Ok, good. now there is a stake in the sand. That you have an issue with
the UDP example of mine is fine for the moment, because I was purposefully
establishing something [far] less ideal. I supplied two examples of varying
complexity and worth and you've precisely placed your position on this.
Thank you for that, now we're /somewhere/.

I think that the nested loop you provide is not only slower (which in this
example is hardly an issue), but a harder to maintain obfuscated mess. Back
in my C days, had one of my guys attempted this, he would have received a
quick conversation from me.

You've taken 3 loops, each of which contained only a single conditional for
the engineer to parse through, and added to each one an additional
conditional that must be parsed and evaluated /by the engineer/ in order to
make sure that any change made to the body of the loop doesn't explode the
loop itself around his ears.

Your following statement of:

The Wogster:
Where the goto becomes a problem, is when do
other stuff is 30 lines, so that the goto is a couple
of screens later, and someone not realizing that
the for gets usurped later on, adds code between
the "for (int z"and the "for (int y" that counts on z
getting to 10.

is incredibly broken logic. If the "do other stuff" were 30 lines, then
you'd *PARTICULARLY* not want the loop you describe. It would require the
engineer to wade through 30 lines of code to make sure that the onlyFisrt
boolean was not altered within it. Furthermore, any change to those 30
lines 4 weeks later by another engineer holds the possibility of breaking
the loop itself even if he's very senior, but hopped on caffeine at 3 am.
You would have dragged the logic of the loop itself into 30 additional
lines, when the loop should have instead merely been just that: a nested
loop containing just the logic needed to form the loop.

I believe that your not-so humble opinion (as we all have from time to time)
is /predicated/ on the notion that goto is bad. Predicated and assumed.
From there you drew further conclusions, rather than weigh the issue at hand
and discover what was truly clearest.

...[rip]...

--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

java-programmer >> 2 extends Thomas G. Marshall wrote:
> The Wogster coughed up:
>
>>Thomas G. Marshall wrote:
>
>
> ...[rip]...
>
>
>>>Take a look at the following in a goto-enabled language:
>>>
>>> for (int z = 0; z < 10; z++)
>>> for (int y = 0; y < 10; y++)
>>> for (int x = 0; x < 10; x++)
>>> if (array[z][y][x] == somethingNeeded)
>>> goto hop_out;
>>> hop_out:
>>> (continue on)
>>>
>>>Is /this/ something that bothers your sensibilities?
>>>
>>
>>Yes, but more that it's a horrible construct, then that it contains a
>>goto.
>>
>>Here is another option, that does the same thing, but is, IMNSHO
>>clearer;
>>bool onlyFirst = true; // only find first somethingNeeded
>>
>>for (int z = 0; z < 10 && onlyFirst == true; z++)
>> for (int y = 0; y < 10 && onlyFirst == true; y++)
>> for (int x = 0; x < 10 && onlyFirst == true; x++)
>> if (array[z][y][x] == somethingNeeded)
>> {
>>onlyFirst == false;
>>// do other stuff
>> }
>
>
> Ok, good. now there is a stake in the sand. That you have an issue with
> the UDP example of mine is fine for the moment, because I was purposefully
> establishing something [far] less ideal. I supplied two examples of varying
> complexity and worth and you've precisely placed your position on this.
> Thank you for that, now we're /somewhere/.
>
> I think that the nested loop you provide is not only slower (which in this
> example is hardly an issue), but a harder to maintain obfuscated mess. Back
> in my C days, had one of my guys attempted this, he would have received a
> quick conversation from me.

See below

>
> You've taken 3 loops, each of which contained only a single conditional for
> the engineer to parse through, and added to each one an additional
> conditional that must be parsed and evaluated /by the engineer/ in order to
> make sure that any change made to the body of the loop doesn't explode the
> loop itself around his ears.
>
> Your following statement of:
>
> The Wogster:
> Where the goto becomes a problem, is when do
> other stuff is 30 lines, so that the goto is a couple
> of screens later, and someone not realizing that
> the for gets usurped later on, adds code between
> the "for (int z"and the "for (int y" that counts on z
> getting to 10.
>
> is incredibly broken logic. If the "do other stuff" were 30 lines, then
> you'd *PARTICULARLY* not want the loop you describe. It would require the
> engineer to wade through 30 lines of code to make sure that the onlyFisrt
> boolean was not altered within it. Furthermore, any change to those 30
> lines 4 weeks later by another engineer holds the possibility of breaking
> the loop itself even if he's very senior, but hopped on caffeine at 3 am.
> You would have dragged the logic of the loop itself into 30 additional
> lines, when the loop should have instead merely been just that: a nested
> loop containing just the logic needed to form the loop.

With the goto, the engineer needs to look for something, they may not
even realize exists. My solution, indicates that the loop has TWO
conditions, which it does, so does yours, but it may not be clear that
there are two conditions, the for only has one condition, even though
the loop has two. That can be dangerous, when the engineer is debugging
code at 3am, knowing that the application takes 6 hours, and needs to be
finish running by 7.

The flag, indicates that there IS two conditions, so a quick search will
find the second condition.

I would like to continue, but don't have more time to spend on this.....

W

>
> I believe that your not-so humble opinion (as we all have from time to time)
> is /predicated/ on the notion that goto is bad. Predicated and assumed.
> From there you drew further conclusions, rather than weigh the issue at hand
> and discover what was truly clearest.
>
>
> ...[rip]...
>
>

java-programmer >> 2 extends The Wogster coughed up:
> Thomas G. Marshall wrote:
>> The Wogster coughed up:
>>
>>> Thomas G. Marshall wrote:
>>
>>
>> ...[rip]...
>>
>>
>>>> Take a look at the following in a goto-enabled language:
>>>>
>>>> for (int z = 0; z < 10; z++)
>>>> for (int y = 0; y < 10; y++)
>>>> for (int x = 0; x < 10; x++)
>>>> if (array[z][y][x] == somethingNeeded)
>>>> goto hop_out;
>>>> hop_out:
>>>> (continue on)
>>>>
>>>> Is /this/ something that bothers your sensibilities?
>>>>
>>>
>>> Yes, but more that it's a horrible construct, then that it contains
>>> a goto.
>>>
>>> Here is another option, that does the same thing, but is, IMNSHO
>>> clearer;
>>> bool onlyFirst = true; // only find first somethingNeeded
>>>
>>> for (int z = 0; z < 10 && onlyFirst == true; z++)
>>> for (int y = 0; y < 10 && onlyFirst == true; y++)
>>> for (int x = 0; x < 10 && onlyFirst == true; x++)
>>> if (array[z][y][x] == somethingNeeded)
>>> {
>>> onlyFirst == false;
>>> // do other stuff
>>> }
>>
>>
>> Ok, good. now there is a stake in the sand. That you have an issue
>> with the UDP example of mine is fine for the moment, because I was
>> purposefully establishing something [far] less ideal. I supplied
>> two examples of varying complexity and worth and you've precisely
>> placed your position on this. Thank you for that, now we're
>> /somewhere/. I think that the nested loop you provide is not only slower
>> (which
>> in this example is hardly an issue), but a harder to maintain
>> obfuscated mess. Back in my C days, had one of my guys attempted
>> this, he would have received a quick conversation from me.
>
> See below
>
>>
>> You've taken 3 loops, each of which contained only a single
>> conditional for the engineer to parse through, and added to each one
>> an additional conditional that must be parsed and evaluated /by the
>> engineer/ in order to make sure that any change made to the body of
>> the loop doesn't explode the loop itself around his ears.
>>
>> Your following statement of:
>>
>> The Wogster:
>> Where the goto becomes a problem, is when do
>> other stuff is 30 lines, so that the goto is a couple
>> of screens later, and someone not realizing that
>> the for gets usurped later on, adds code between
>> the "for (int z"and the "for (int y" that counts on z
>> getting to 10.
>>
>> is incredibly broken logic. If the "do other stuff" were 30 lines,
>> then you'd *PARTICULARLY* not want the loop you describe. It would
>> require the engineer to wade through 30 lines of code to make sure
>> that the onlyFisrt boolean was not altered within it. Furthermore,
>> any change to those 30 lines 4 weeks later by another engineer holds
>> the possibility of breaking the loop itself even if he's very
>> senior, but hopped on caffeine at 3 am. You would have dragged the
>> logic of the loop itself into 30 additional lines, when the loop
>> should have instead merely been just that: a nested loop containing
>> just the logic needed to form the loop.
>
> With the goto, the engineer needs to look for something, they may not
> even realize exists. My solution, indicates that the loop has TWO
> conditions, which it does, so does yours, but it may not be clear that
> there are two conditions, the for only has one condition, even though
> the loop has two. That can be dangerous, when the engineer is
> debugging code at 3am, knowing that the application takes 6 hours,
> and needs to be finish running by 7.
>
> The flag, indicates that there IS two conditions, so a quick search
> will find the second condition.

Now you're grasping at straws.

In my case, each nested for() has a single conditional making 3 visible to
the engineer. Add to this a conditional test within the 3 layer loop for
exit. There is nothing hidden here at all.

In your case, each for() has 2 conditionals making 6. Add to this the same
conditional test I have in the middle, but place the code within the body of
the loop where it is possible to truly muck up the looping logic.

> I would like to continue, but don't have more time to spend on
> this.....

I too am getting tired. It's not that we disagree that is so tiring, but I
just cannot even get /close/ to understanding your logic in this regard, try
as I might to spell the examples out.

You don't think so of course, but I still suspect that if you really thought
it through honestly that you'd realize that much of your knee-jerk dismissal
of the goto is only based upon itself and not on evidence. That you loathed
it first, and then looked for and found the reasons why.

But in any case, we're certainly going nowhere fast.

Thanks for the discussion.

...[rip]...

--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/

java-programmer >> 2 extends Thomas G. Marshall wrote:
> The Wogster coughed up:
>
>>Thomas G. Marshall wrote:
>>
>>>The Wogster coughed up:
>>>
>>>
>>>>Thomas G. Marshall wrote:
>>>
>>>
>>>...[rip]...
>>>
>>>
>>>
>>>>>Take a look at the following in a goto-enabled language:
>>>>>
>>>>> for (int z = 0; z < 10; z++)
>>>>> for (int y = 0; y < 10; y++)
>>>>> for (int x = 0; x < 10; x++)
>>>>> if (array[z][y][x] == somethingNeeded)
>>>>> goto hop_out;
>>>>> hop_out:
>>>>> (continue on)
>>>>>
>>>>>Is /this/ something that bothers your sensibilities?
>>>>>
>>>>
>>>>Yes, but more that it's a horrible construct, then that it contains
>>>>a goto.
>>>>
>>>>Here is another option, that does the same thing, but is, IMNSHO
>>>>clearer;
>>>>bool onlyFirst = true; // only find first somethingNeeded
>>>>
>>>>for (int z = 0; z < 10 && onlyFirst == true; z++)
>>>>for (int y = 0; y < 10 && onlyFirst == true; y++)
>>>> for (int x = 0; x < 10 && onlyFirst == true; x++)
>>>> if (array[z][y][x] == somethingNeeded)
>>>> {
>>>>onlyFirst == false;
>>>>// do other stuff
>>>> }
>>>
>>>
>>>Ok, good. now there is a stake in the sand. That you have an issue
>>>with the UDP example of mine is fine for the moment, because I was
>>>purposefully establishing something [far] less ideal. I supplied
>>>two examples of varying complexity and worth and you've precisely
>>>placed your position on this. Thank you for that, now we're
>>>/somewhere/. I think that the nested loop you provide is not only slower
>>>(which
>>>in this example is hardly an issue), but a harder to maintain
>>>obfuscated mess. Back in my C days, had one of my guys attempted
>>>this, he would have received a quick conversation from me.
>>
>>See below
>>
>>
>>>You've taken 3 loops, each of which contained only a single
>>>conditional for the engineer to parse through, and added to each one
>>>an additional conditional that must be parsed and evaluated /by the
>>>engineer/ in order to make sure that any change made to the body of
>>>the loop doesn't explode the loop itself around his ears.
>>>
>>>Your following statement of:
>>>
>>> The Wogster:
>>> Where the goto becomes a problem, is when do
>>> other stuff is 30 lines, so that the goto is a couple
>>> of screens later, and someone not realizing that
>>> the for gets usurped later on, adds code between
>>> the "for (int z"and the "for (int y" that counts on z
>>> getting to 10.
>>>
>>>is incredibly broken logic. If the "do other stuff" were 30 lines,
>>>then you'd *PARTICULARLY* not want the loop you describe. It would
>>>require the engineer to wade through 30 lines of code to make sure
>>>that the onlyFisrt boolean was not altered within it. Furthermore,
>>>any change to those 30 lines 4 weeks later by another engineer holds
>>>the possibility of breaking the loop itself even if he's very
>>>senior, but hopped on caffeine at 3 am. You would have dragged the
>>>logic of the loop itself into 30 additional lines, when the loop
>>>should have instead merely been just that: a nested loop containing
>>>just the logic needed to form the loop.
>>
>>With the goto, the engineer needs to look for something, they may not
>>even realize exists. My solution, indicates that the loop has TWO
>>conditions, which it does, so does yours, but it may not be clear that
>>there are two conditions, the for only has one condition, even though
>>the loop has two. That can be dangerous, when the engineer is
>>debugging code at 3am, knowing that the application takes 6 hours,
>>and needs to be finish running by 7.
>>
>>The flag, indicates that there IS two conditions, so a quick search
>>will find the second condition.
>
>
>
> Now you're grasping at straws.
>
> In my case, each nested for() has a single conditional making 3 visible to
> the engineer. Add to this a conditional test within the 3 layer loop for
> exit. There is nothing hidden here at all.
>
> In your case, each for() has 2 conditionals making 6. Add to this the same
> conditional test I have in the middle, but place the code within the body of
> the loop where it is possible to truly muck up the looping logic.
>

Actually there are just as many conditions with your loop structure,
however it's ONLY clear if you either document it (unlikely), or the
code is a small snippet like in the example. However if there is a lot
of code, there is nothing in the code to connect the goto to the loop,
so here is where it starts looking more difficult:

for (int z = 0; z < 10; z++)
for (int y = 0; y < 10; y++)
for (int x = 0; x < 10; x++)
if (array[z][y][x] == somethingNeeded)
{
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
// more lines of code
goto hop_out;
}
hop_out:

Yes, this code is legal (C and C++ at least), even though it's confusing
, because you may not remember (a year later) that the goto is connected
to any of the loops. The flag version, may contain more conditionals,
however you know that the loop is connected to it, even though the
number of comments is the same. In other words the flag documents
itself. You know that another condition is connected to the loop.

You know as well as I do, that most C programmers would rather have
themselves boiled in oil, have all of their fingernails pulled out, and
be keel-hauled in acid then to voluntarily write the combination /* or
// any more often then required by employer standards.

Another possible way to write this is this way:

bool onlyFirst = true;
for (int z = 0; z < 10; z++)
{
for (int y = 0; y < 10; y++)
{
for (int x = 0; x < 10; x++)
{
if (array[z][y][x] == somethingNeeded && onlyFirst )
{
onlyFirst = false;
// do stuff
}
} // for (int x
} // for (int y
} // for (int z

In this case, you simply let the loops "deadhead" to completion, knowing
that the innermost condition will not trigger a second time, because the
condition can not be met the subsequent times. Of course you probably
don't like this either, it wastes some time running the loops, but in a
day when most processors are 1GHz and higher, that doesn't really matter
much.

However it still documents itself, and you can't get tripped up, by a
loop that does not complete. Even though the braces are not needed, I
usually put them in, along with the decorations, only because it makes
the code far easier to read, especially a year later when you can't
remember what you did, and the } is over a screen length away from the
related for.

W

>
>
>>I would like to continue, but don't have more time to spend on
>>this.....
>
>
>
> I too am getting tired. It's not that we disagree that is so tiring, but I
> just cannot even get /close/ to understanding your logic in this regard, try
> as I might to spell the examples out.
>
> You don't think so of course, but I still suspect that if you really thought
> it through honestly that you'd realize that much of your knee-jerk dismissal
> of the goto is only based upon itself and not on evidence. That you loathed
> it first, and then looked for and found the reasons why.
>
> But in any case, we're certainly going nowhere fast.
>
> Thanks for the discussion.
>

java-programmer >> 2 extends The Wogster coughed up:
> Thomas G. Marshall wrote:

...[rip]...

>> In my case, each nested for() has a single conditional making 3
>> visible to the engineer. Add to this a conditional test within the
>> 3 layer loop for exit. There is nothing hidden here at all.
>>
>> In your case, each for() has 2 conditionals making 6. Add to this
>> the same conditional test I have in the middle, but place the code
>> within the body of the loop where it is possible to truly muck up
>> the looping logic.
>
> Actually there are just as many conditions

Nope. Only if you count the compound conditional as a single entity.

I'm regarding

for (int x = 0; x < 10; x++)

as easier to read than checking your *two* items, as you put it here:

for (int x = 0; x < 10 && onlyFirst==true; x++)

> with your loop structure,
> however it's ONLY clear if you either document it (unlikely), or the
> code is a small snippet like in the example. However if there is a
> lot of code, there is nothing in the code to connect the goto to the
> loop, so here is where it starts looking more difficult:
>
> for (int z = 0; z < 10; z++)
> for (int y = 0; y < 10; y++)
> for (int x = 0; x < 10; x++)
> if (array[z][y][x] == somethingNeeded)
> {
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code

You forgot 3 :)
// more lines of code
// more lines of code
// more lines of code

> goto hop_out;
> }
> hop_out:

This is hardly what I was advocating! *If* we're going to spell out the 30
lines of code, then this is what it *should* look like.

for (int z = 0; z < 10; z++)
for (int y = 0; y < 10; y++)
for (int x = 0; x < 10; x++)
if (array[z][y][x] == somethingNeeded)
goto found;

//Not found handling here.

found:
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code
> // more lines of code

In this way, the *entirety* of the loop is visible, and it is accomplishing
precisely one thing: the search. What happens as a *result* of *finding*
the first item is handled afterward, as it should be.

Keep those 30 lines the heck out of the loop, so that the tired engineer at
3am can see it easily and not @#$% up the boolean you added to each of the 3
nested checks.

And Keep those 30 lines the heck out of the loop because they are not being
done more than once anyway, as the bodies of loops are most often seen to
do.

...[rip]...

--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."

java-programmer >> 2 extends Thomas G. Marshall wrote:
> The Wogster coughed up:
>
>>Thomas G. Marshall wrote:
>
>
> ...[rip]...
>
>
>>>In my case, each nested for() has a single conditional making 3
>>>visible to the engineer. Add to this a conditional test within the
>>>3 layer loop for exit. There is nothing hidden here at all.
>>>
>>>In your case, each for() has 2 conditionals making 6. Add to this
>>>the same conditional test I have in the middle, but place the code
>>>within the body of the loop where it is possible to truly muck up
>>>the looping logic.
>>
>>Actually there are just as many conditions
>
>
> Nope. Only if you count the compound conditional as a single entity.
>
> I'm regarding
>
> for (int x = 0; x < 10; x++)
>
> as easier to read than checking your *two* items, as you put it here:
>
> for (int x = 0; x < 10 && onlyFirst==true; x++)
>
>
>>with your loop structure,
>>however it's ONLY clear if you either document it (unlikely), or the
>>code is a small snippet like in the example. However if there is a
>>lot of code, there is nothing in the code to connect the goto to the
>>loop, so here is where it starts looking more difficult:
>>
>>for (int z = 0; z < 10; z++)
>> for (int y = 0; y < 10; y++)
>> for (int x = 0; x < 10; x++)
>> if (array[z][y][x] == somethingNeeded)
>> {
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>>// more lines of code
>
>
> You forgot 3 :)
> // more lines of code
> // more lines of code
> // more lines of code
>
>
>> goto hop_out;
>> }
>>hop_out:
>
>
>
> This is hardly what I was advocating! *If* we're going to spell out the 30
> lines of code, then this is what it *should* look like.
>
> for (int z = 0; z < 10; z++)
> for (int y = 0; y < 10; y++)
> for (int x = 0; x < 10; x++)
> if (array[z][y][x] == somethingNeeded)
> goto found;
>
> //Not found handling here.
>
> found:
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
> > // more lines of code
>
> In this way, the *entirety* of the loop is visible, and it is accomplishing
> precisely one thing: the search. What happens as a *result* of *finding*
> the first item is handled afterward, as it should be.
>
> Keep those 30 lines the heck out of the loop, so that the tired engineer at
> 3am can see it easily and not @#$% up the boolean you added to each of the 3
> nested checks.
>
> And Keep those 30 lines the heck out of the loop because they are not being
> done more than once anyway, as the bodies of loops are most often seen to
> do.
>
>

So what we really end up with is something like this:

for (int z = 0; z < 10; z++)
for (int y = 0; y < 10; y++)
for (int x = 0; x < 10; x++)
if (array[z][y][x] == somethingNeeded)
goto found;

//Not found handling here.
goto skipfound:
found:
// more lines of code
.
. <skip>
.
// more lines of code
skipfound:
// more code that gets executed regardless.

So with 6 lines of logic (not including the labels, and other code) we
have 2 goto statements, your coming up a batch of spaghetti here.... I
prefer noodles, with a nice alfredo sauce, and some chicken mixed in, on
a plate, not on my screen.

Worse still, 3 years from now, when they need the if to iterate over
each occurance of something needed, and not just the first one, you need
to do a rewrite, or add even more gotos..... Where as the switching of
the flag can simply be commented out, which is why I came up with my
second version, something you never did comment on.....

Oh well, I need to go....

W

java-programmer >> 2 extends The Wogster coughed up:
> Thomas G. Marshall wrote:
>> The Wogster coughed up:
>>
>>> Thomas G. Marshall wrote:
>>
>>
>> ...[rip]...
>>
>>
>>>> In my case, each nested for() has a single conditional making 3
>>>> visible to the engineer. Add to this a conditional test within the
>>>> 3 layer loop for exit. There is nothing hidden here at all.
>>>>
>>>> In your case, each for() has 2 conditionals making 6. Add to this
>>>> the same conditional test I have in the middle, but place the code
>>>> within the body of the loop where it is possible to truly muck up
>>>> the looping logic.
>>>
>>> Actually there are just as many conditions
>>
>>
>> Nope. Only if you count the compound conditional as a single entity.
>>
>> I'm regarding
>>
>> for (int x = 0; x < 10; x++)
>>
>> as easier to read than checking your *two* items, as you put it here:
>>
>> for (int x = 0; x < 10 && onlyFirst==true; x++)
>>
>>
>>> with your loop structure,
>>> however it's ONLY clear if you either document it (unlikely), or the
>>> code is a small snippet like in the example. However if there is a
>>> lot of code, there is nothing in the code to connect the goto to the
>>> loop, so here is where it starts looking more difficult:
>>>
>>> for (int z = 0; z < 10; z++)
>>> for (int y = 0; y < 10; y++)
>>> for (int x = 0; x < 10; x++)
>>> if (array[z][y][x] == somethingNeeded)
>>> {
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>> // more lines of code
>>
>>
>> You forgot 3 :)
>> // more lines of code
>> // more lines of code
>> // more lines of code
>>
>>
>>> goto hop_out;
>>> }
>>> hop_out:
>>
>>
>>
>> This is hardly what I was advocating! *If* we're going to spell out
>> the 30 lines of code, then this is what it *should* look like.
>>
>> for (int z = 0; z < 10; z++)
>> for (int y = 0; y < 10; y++)
>> for (int x = 0; x < 10; x++)
>> if (array[z][y][x] == somethingNeeded)
>> goto found;
>>
>> //Not found handling here.
>>
>> found:
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>> > // more lines of code
>>
>> In this way, the *entirety* of the loop is visible, and it is
>> accomplishing precisely one thing: the search. What happens as a
>> *result* of *finding* the first item is handled afterward, as it
>> should be. Keep those 30 lines the heck out of the loop, so that the
>> tired
>> engineer at 3am can see it easily and not @#$% up the boolean you
>> added to each of the 3 nested checks.
>>
>> And Keep those 30 lines the heck out of the loop because they are
>> not being done more than once anyway, as the bodies of loops are
>> most often seen to do.
>>
>>
>
>
> So what we really end up with is something like this:
>
>
> for (int z = 0; z < 10; z++)
> for (int y = 0; y < 10; y++)
> for (int x = 0; x < 10; x++)
> if (array[z][y][x] == somethingNeeded)
> goto found;
>
> //Not found handling here.
> goto skipfound:
> found:
> // more lines of code
> .
> . <skip>
> .
> // more lines of code
> skipfound:
> // more code that gets executed regardless.

Interesting technique: you've taken my example and added a goto to it in
order to make it look like it's overusing goto. This is a different example
where you have three pertinent sections:

found after searching and executed
non found after searching and executed
executed either way after searching

which has little to do with my example of two sections, something you still
didn't like and even opted for that extra flag check in each for() level and
placing the code executed once the thing was found /into/ the middle of the
loop, which as I pointed out opens you up for maintainability problems.

If you absolutely *must* honor all three possibilities in the same function,
then I would probably /then/ use a boolean for use /after/ the goto, but not
within the loop conditionals for obfuscation, and I certainly wouldn't have
the main logic appear within the loop like you favor. (again, this is an
arbitrary goto-enabled language):

boolean found = false;

for (int z = 0; z < 10; z++)
for (int y = 0; y < 10; y++)
for (int x = 0; x < 10; x++)
if (array[z][y][x] == somethingNeeded)
{
found = true;
goto hopped_out;
}

hopped_out:

if (found)
{
foundcode;
foundcode;
foundcode;
}
else // (!found)
{
notfoundcode;
notfoundcode;
notfoundcode;
}

bothcode;
bothcode;
bothcode;

...[rip]...

> Worse still, 3 years from now, when they need the if to iterate over
> each occurance of something needed, and not just the first one, you
> need to do a rewrite, or add even more gotos..... Where as the
> switching of the flag can simply be commented out, which is why I
> came up with my second version, something you never did comment
> on.....

I'm specifically commenting on things as close to one at a time as I can for
focus. This thread is out of hand as it is. In fact, too far so. If you
insist, then here is your example:

bool onlyFirst = true;
for (int z = 0; z < 10; z++)
{
for (int y = 0; y < 10; y++)
{
for (int x = 0; x < 10; x++)
{
if (array[z][y][x] == somethingNeeded && onlyFirst )
{
onlyFirst = false;
// do stuff
}
} // for (int x
} // for (int y
} // for (int z

You certainly can't be serious! Making loops run to completion
unnecessarily? What if the array is enlarged significantly? What if this
were done in multiple threads on top of all that?

There is such a thing as over-optimization, but terminating a loop when the
looping is no longer needed is certainly not one of them!

We really are going nowhere.

...[rip]...

--
Sometimes life just sucks and then you live.

java-programmer >> 2 extends Thomas G. Marshall wrote:
>
> We really are going nowhere.
>

Agreed, thread ended.

W

java-programmer >> 2 extends The Wogster wrote:
> Thomas G. Marshall wrote:
>>
>> We really are going nowhere.
>>
>
> Agreed, thread ended.
>
> W

34 messages in the thread (now 35...). Who wins the pool?

--
Virgil

java-programmer >> 2 extends Virgil Green wrote:
> The Wogster wrote:
>
>>Thomas G. Marshall wrote:
>>
>>>We really are going nowhere.
>>>
>>
>>Agreed, thread ended.
>>
>>W
>
>
> 34 messages in the thread (now 35...). Who wins the pool?
>

Having done additional thinking on this, the thread may have, to a large
degree, proved my point, when you absolutely need a goto, then your
design needs to be revisited.

Everyone who studies C, C++, Java, Basic or any other language that
contains a for statement, knows it's intended for fixed-length loops, so
perhaps the ideal is to use a different looping construct, such as a
while or do-while, loop-until or whatever else the language offers.

Then again looking for a specific value in a 3 dimensional array, should
probably be taking into account the other dimensions. Most searches on
multi-dimensional arrays, are only searching within one of the
dimensions, not all of the dimensions. Efficiency is not the name of
the game when the value your looking for in a 1000 x 1000 x 1000
dimensioned array is array[999][999][999]....

W

java-programmer >> 2 extends The Wogster coughed up:
> Virgil Green wrote:
>> The Wogster wrote:
>>
>>> Thomas G. Marshall wrote:
>>>
>>>> We really are going nowhere.
>>>>
>>>
>>> Agreed, thread ended.
>>>
>>> W
>>
>>
>> 34 messages in the thread (now 35...). Who wins the pool?
>>
>
> Having done additional thinking on this, the thread may have, to a
> large degree, proved my point

No it didn't, and not to any degree. And attempting to revive this thread
as an attempt to claim false victory and throw in additional points is
hardly an intelligent idea.

--
Having a dog that is a purebred does not qualify it for breeding. Dogs
need to have several generations of clearances for various illnesses
before being bred. If you are breeding dogs without taking care as to
the genetic quality of the dog (again, being purebred is *not* enough),
you are what is known as a "backyard breeder" and are part of the
problem. Most of the congenital problems of present day dogs are
traceable directly to backyard breeding. Spay or neuter your pet
responsibly, and don't just think that you're somehow the exception and
can breed a dog without taking the care described.

java-programmer >> 2 extends Bryce coughed up:
> On Fri, 10 Jun 2005 22:43:04 GMT, "Thomas G. Marshall"
> <email***@***.com> wrote:
>
>> Bryce coughed up:
>>> On Thu, 9 Jun 2005 13:38:40 +0200, "Irlan agous" <email***@***.com>
>>> wrote:
>>>
>>>> Hello i want to extend from 2 classes lik
>>>>
>>>> public class PatientImpl extends DataModel ,UnicastRemoteObject
>>>> implements PatientInterface throws RemoteExeption;
>>>>
>>>> But this gives an error message, dfoes anyone knows how to solve
>>>> this?
>>>
>>> No multiple inheritence in Java.
>>
>> {cough, cough}....except for interfaces.
>
> Well, That's not technically inheritence...
>
> Java classes inherit other classes
> Java classes implement interfaces.
>
> But I get the point, and duly noted

Are you sure? Take a look at the following:

interface A { void a(); }
interface B { void b(); }
interface C extends A,B { void c(); }

C is a valid interface declaration. It requires a(), b(), and c().

--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."