comments to VB.NET Raises Hackles

[Juergen]

Some comments to the article in the internet. I've just recoded an Internet-Program
(some thousand lines) from asp to aspx, only to learn, so I know (partial)
what I'm talking about.
->They've broken VB! Not true.
Don't agree. The "huge in technology" is a simple step. We have been waiting
for this a very long time. But there is no reason, to change the coding in
the way they did.
->The changes are unnecesarry
Why could'nt we use a int with 16 bit (for example) ?
->No Gosubs
This is not wearth to mention. You should better use real arguments
->Nobody cares about cross-language compatibility!
This is no reason to change something like dim of arrays (for example)
->There Are No Experts Anymore
The arguments sounds like "There are old guys, they will never learn and
there new guys at the front of programming" That's too simple, you should'nt
try to split the programmers in two parts. MS has done all this, to make
their job easier, not to help all the programmers.

[William Cleveland]

Juergen wrote:
>
> Some comments to the article in the internet. I've just recoded an Internet-Program
> (some thousand lines) from asp to aspx, only to learn, so I know (partial)
> what I'm talking about.
>
> ->No Gosubs
> This is not wearth to mention. You should better use real arguments

Am I the only person in the world who actually likes GOSUB/RETURN? I'd
rather have real nested subroutines like PASCAL does, but these are
still handy on occasion.

Bill

[Jonathan Allen]

> Am I the only person in the world who actually likes GOSUB/RETURN?

No, there are a few people still using them. However, most gave them up when
QBasic was released.

--
Jonathan Allen

"When considering performance, one must rate accuracy over speed. No one
cares how fast you can give the wrong answer." - Anonymous


"William Cleveland" <WCleveland@Mediaone.Net> wrote in message
news:3A7D96FE.1AC079A0@Mediaone.Net...
> Juergen wrote:
> >
> > Some comments to the article in the internet. I've just recoded an
Internet-Program
> > (some thousand lines) from asp to aspx, only to learn, so I know
(partial)
> > what I'm talking about.
> >
> > ->No Gosubs
> > This is not wearth to mention. You should better use real arguments
>
> Am I the only person in the world who actually likes GOSUB/RETURN? I'd
> rather have real nested subroutines like PASCAL does, but these are
> still handy on occasion.
>
> Bill

[Dan Barclay]

On Sun, 4 Feb 2001 12:26:50 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> Am I the only person in the world who actually likes GOSUB/RETURN?
>
>No, there are a few people still using them. However, most gave them up when
>QBasic was released.

"Most"? I question your information. Can you cite?

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jonathan Allen]

> "Most"? I question your information. Can you cite?

Unfortunately, it is only anecdotal. All of the programming teachers I have
had forbid any use Goto or Gosub (except assembly classes). Every programmer
I know personally also frowns on its use.

--
Jonathan Allen

"When considering performance, one must rate accuracy over speed. No one
cares how fast you can give the wrong answer." - Anonymous


"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:l3au7tgobp4uafuoub7iqbkhkeko8o8m7r@4ax.com...
> On Sun, 4 Feb 2001 12:26:50 -0800, "Jonathan Allen"
> <greywolfcs@bigfoot.com> wrote:
>
> >> Am I the only person in the world who actually likes GOSUB/RETURN?
> >
> >No, there are a few people still using them. However, most gave them up
when
> >QBasic was released.
>
> "Most"? I question your information. Can you cite?
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Dan Barclay]

On Mon, 5 Feb 2001 14:37:54 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> "Most"? I question your information. Can you cite?
>
>Unfortunately, it is only anecdotal. All of the programming teachers I have
>had forbid any use Goto or Gosub (except assembly classes). Every programmer
>I know personally also frowns on its use.

Not every programmer I know of frowns on its use, nor do they use them
every other line. GoTo has its place, as does GoSub.

If you had programming teachers who forbid Goto or Gosub, maybe they
should get out and write some real code. You should learn how to
properly use the tools you have.

Eliminating multiple copies of procedure calls with long parameter
lists, and eliminating duplicate code fragments should be a clear
objective. In the real world they are a source of error once
maintenance starts.

Of course, if all you do is "write once" then throw away the code you
can just cut/paste and not worry about it. No need for GoSub at all.

Now, back to the "Most" question. You're answering this like you
might know something about it... then you say "uhhhh". You have no
friggin' *clue* how much GoSub is used.

You and some others around here claiming to be Master Programmers
start talking about how stupid it is to use GoSub. Because you claim
to know what you're doing, some people actually think you do. My bet
is that there are more people lurking here who use GoSub. I use it,
and I have the guts to admit it. It's a valuable tool.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Joe \Nuke Me Xemu\ Foster]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message <news:3a7f2ee2@news.devx.com>...

> > "Most"? I question your information. Can you cite?
>
> Unfortunately, it is only anecdotal. All of the programming teachers I have
> had forbid any use Goto or Gosub (except assembly classes). Every programmer
> I know personally also frowns on its use.

There are situations in which GOTO and its ilk really do suck less
than the approved alternatives:

<http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt>

I wonder if Delphi/Object Pascal/FlavorOfTheMonth has inherited the
misfeatures discussed?

--
Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Jay Glynn]

Dan,

> If you had programming teachers who forbid Goto or Gosub, maybe they
> should get out and write some real code. You should learn how to
> properly use the tools you have.

And how to keep from writing spaghetti.

> Eliminating multiple copies of procedure calls with long parameter
> lists, and eliminating duplicate code fragments should be a clear
> objective. In the real world they are a source of error once
> maintenance starts.

And gosubs and gotos aren't a source of problems and confusion as well?

> You and some others around here claiming to be Master Programmers
> start talking about how stupid it is to use GoSub. Because you claim
> to know what you're doing, some people actually think you do. My bet
> is that there are more people lurking here who use GoSub. I use it,
> and I have the guts to admit it. It's a valuable tool.

I don't know about we, but I do know what I am doing, and yes, if used
properly a gosub or a goto doesn't cause any real headache. The problem is
that the line between properly and chaos is very thin, and can be crossed
easily. As far as maint, gotos make maint and upgrades a nightmare,
especially in a multi-developer environment. If you are the only one that
looks at the code, then do whatever blows your dress up, however in a team
setting, these 2 can be very dangerous.
--
Jay Glynn
Introducing .NET
ISBN: 1861004893
Wrox Press Ltd.

[Dan Barclay]

On Mon, 5 Feb 2001 20:16:12 -0600, "Jay Glynn" <jay_glynn@agla.com>
wrote:

>Dan,
>
>> If you had programming teachers who forbid Goto or Gosub, maybe they
>> should get out and write some real code. You should learn how to
>> properly use the tools you have.
>
>And how to keep from writing spaghetti.

If someone can't program they can't program. All the tools in the
world (or removing all but 3 features) will not prevent crap from
being written.

>
>> Eliminating multiple copies of procedure calls with long parameter
>> lists, and eliminating duplicate code fragments should be a clear
>> objective. In the real world they are a source of error once
>> maintenance starts.
>
>And gosubs and gotos aren't a source of problems and confusion as well?

No, they aren't. Crappy code is a source of problems and confusion.
To think that you eliminate problems by removing tools is silly.

If you take an idiot and have him reproduce the same startup/cleanup
code fragments within 20 Cases of a 30 Case Select, you've got a
boatload of problems. Sometimes the way to eliminate that is to wrap
those fragments in a procedure. Other times the best way is to put
the fragments in a labeled procedure and GoSub/Return.

>> You and some others around here claiming to be Master Programmers
>> start talking about how stupid it is to use GoSub. Because you claim
>> to know what you're doing, some people actually think you do. My bet
>> is that there are more people lurking here who use GoSub. I use it,
>> and I have the guts to admit it. It's a valuable tool.
>
>I don't know about we, but I do know what I am doing, and yes, if used
>properly a gosub or a goto doesn't cause any real headache. The problem is
>that the line between properly and chaos is very thin, and can be crossed
>easily.

It's not that thin, actually. What's more, with only a little
discipline to keep the labeled procedures consistent you eliminate a
*lot* of potential problems. My only regret is that they don't let
<shift-F8> jump the GoSub like they do with a Sub or Function.

>As far as maint, gotos make maint and upgrades a nightmare,
>especially in a multi-developer environment.

GoTo's are quite useful for jumping *cleanly* out of deeply nested
flow control (Do/For/etc). You can *greatly* increase readability...
or you can screw it up badly. Likewise, you can use Exit ThisAndThat
to work your way out and have it readable, or screwed up badly.

>If you are the only one that
>looks at the code, then do whatever blows your dress up, however in a team
>setting, these 2 can be very dangerous.

*Anything* you do in an app of any significant size can be very
dangerous. Team setting or not, bad code is bad code. If you have a
team that doesn't know how to use GoSubs or GoTo's effectively, teach
them or forbid them. I submit that if you can't teach them how to use
the tools correctly you may need to look for another team. Don't,
however, think you know enough about Basic programming to presume to
tell the rest of the world *they* shouldn't use them.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jonathan Allen]

> There are situations in which GOTO and its ilk really do suck less
> than the approved alternatives:

I still use Goto when the control structure I really want doesn't exist.
GoSub, on the other hand, is no longer necessary with the addition of real
subs.

--
Jonathan Allen

"When considering performance, one must rate accuracy over speed. No one
cares how fast you can give the wrong answer." - Anonymous


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3a7f54d7@news.devx.com...
> "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
<news:3a7f2ee2@news.devx.com>...
>
> > > "Most"? I question your information. Can you cite?
> >
> > Unfortunately, it is only anecdotal. All of the programming teachers I
have
> > had forbid any use Goto or Gosub (except assembly classes). Every
programmer
> > I know personally also frowns on its use.
>
> There are situations in which GOTO and its ilk really do suck less
> than the approved alternatives:
>
>
<http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopex
it.txt>
>
> I wonder if Delphi/Object Pascal/FlavorOfTheMonth has inherited the
> misfeatures discussed?
>
> --
> Joe Foster <mailto:jfoster@ricochet.net> Got Thetans?
<http://www.xenu.net/>
> WARNING: I cannot be held responsible for the above They're
coming to
> because my cats have apparently learned to type. take me away,
ha ha!
>
>

[Larry Serflaten]

I never used Pascal, but why was there no reverse loop:

Their Loop and a Half problem:

"The problem is to implement Search in such a way that it returns the least index i for
which list[i] is equal to key; if the value key does not appear in list, the function
Search should return 0. Functions that have this basic structure come up frequently
in programming, even at the introductory level."
(n = number of items in list)

function Search(var list: IntList;
n, key: integer) : integer;
var
i: integer;
begin
for i := 1 to n do
if list[i] = key then return i;
return 0
end;

The 'difficult' correct method:

function Search(var list: IntList;
n, key: integer) : integer;
var
i: integer;
found: boolean;
begin
i := 1;
found := FALSE;
while (i <= n) and not found do
if list[i] = key then
found := TRUE
else
i := i + 1;
if found then
Search := i
else
Search := 0
end;


Could be solved by starting at the end of the list and moving toward the start:

function Search(var list: IntList;
n, key: integer) : integer;
var
i: integer;
begin
i := n;
while (i >= 1) do
if list[i] = key then Search = i;
i := i - 1;
end;

Again, I don't do Pascal, but their major problems (when to exit, and if n = 0)
are taken care of in the above 'pseudo' code

Anyone got a clue why that won't work, or why it wasn't mentioned?

LFS

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message news:3a7f54d7@news.devx.com...
> "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message <news:3a7f2ee2@news.devx.com>...
>
> > > "Most"? I question your information. Can you cite?
> >
> > Unfortunately, it is only anecdotal. All of the programming teachers I have
> > had forbid any use Goto or Gosub (except assembly classes). Every programmer
> > I know personally also frowns on its use.
>
> There are situations in which GOTO and its ilk really do suck less
> than the approved alternatives:
>
> <http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt>
>
> I wonder if Delphi/Object Pascal/FlavorOfTheMonth has inherited the
> misfeatures discussed?

[Jonathan Allen]

> If you had programming teachers who forbid Goto or Gosub, maybe they
> should get out and write some real code. You should learn how to
> properly use the tools you have.

Just because you can do something doesn't mean you should. Learning your
tools covers not only knowing what you can do, but also knowing if you
should do it.

> Eliminating multiple copies of procedure calls with long parameter
> lists, and eliminating duplicate code fragments should be a clear
> objective. In the real world they are a source of error once
> maintenance starts.

Clean and easy to follow code is more important than removing a few
duplicated fragments.

Lets play a game. Post a real-life, production grade method that uses a
gosub and we will try to remove the need for the gosub.

--
Jonathan Allen

"When considering performance, one must rate accuracy over speed. No one
cares how fast you can give the wrong answer." - Anonymous


"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:i2ju7t4dht01lc3p45stptsthimr00l6q6@4ax.com...
> On Mon, 5 Feb 2001 14:37:54 -0800, "Jonathan Allen"
> <greywolfcs@bigfoot.com> wrote:
>
> >> "Most"? I question your information. Can you cite?
> >
> >Unfortunately, it is only anecdotal. All of the programming teachers I
have
> >had forbid any use Goto or Gosub (except assembly classes). Every
programmer
> >I know personally also frowns on its use.
>
> Not every programmer I know of frowns on its use, nor do they use them
> every other line. GoTo has its place, as does GoSub.
>
> If you had programming teachers who forbid Goto or Gosub, maybe they
> should get out and write some real code. You should learn how to
> properly use the tools you have.
>
> Eliminating multiple copies of procedure calls with long parameter
> lists, and eliminating duplicate code fragments should be a clear
> objective. In the real world they are a source of error once
> maintenance starts.
>
> Of course, if all you do is "write once" then throw away the code you
> can just cut/paste and not worry about it. No need for GoSub at all.
>
> Now, back to the "Most" question. You're answering this like you
> might know something about it... then you say "uhhhh". You have no
> friggin' *clue* how much GoSub is used.
>
> You and some others around here claiming to be Master Programmers
> start talking about how stupid it is to use GoSub. Because you claim
> to know what you're doing, some people actually think you do. My bet
> is that there are more people lurking here who use GoSub. I use it,
> and I have the guts to admit it. It's a valuable tool.
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Dan Barclay]

On Mon, 5 Feb 2001 19:10:57 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> There are situations in which GOTO and its ilk really do suck less
>> than the approved alternatives:
>
>I still use Goto when the control structure I really want doesn't exist.

Yes.

>GoSub, on the other hand, is no longer necessary with the addition of real
>subs.

You'll be happy to know you "If" is no longer necessary either.

What's "necessary" got to do with it? Sometimes it's a better fit
than a real sub, just as GoTo is sometimes a better fit than existing
control structures. I can assure you that anytime you use GoTo, some
structure-zealot will be able to show you how to do without it using
"real" flow control. In one case you follow logic to one conclusion,
in the other case to another conclusion... but the issues are the
same.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Dan Barclay]

On Mon, 5 Feb 2001 19:22:49 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> If you had programming teachers who forbid Goto or Gosub, maybe they
>> should get out and write some real code. You should learn how to
>> properly use the tools you have.
>
>Just because you can do something doesn't mean you should. Learning your
>tools covers not only knowing what you can do, but also knowing if you
>should do it.

I absolutely agree.

>> Eliminating multiple copies of procedure calls with long parameter
>> lists, and eliminating duplicate code fragments should be a clear
>> objective. In the real world they are a source of error once
>> maintenance starts.
>
>Clean and easy to follow code is more important than removing a few
>duplicated fragments.

First, you don't need to have bad code in order to eliminate
duplicated fragments. It's silly to contend that you do! What kind
of logic is that?

Second, if you maintain code with duplicate fragments for very long
you're eventually going to change one and not another. It's called a
bug, and it will grow.

>Lets play a game. Post a real-life, production grade method that uses a
>gosub and we will try to remove the need for the gosub.

Remove the need for the gosub? ****, *no* gosub is *needed*. Who are
you trying to kid here? The issue is whether a gosub is a useful
tool. I contend it is.

One example is as a wrapper for a "real" sub with a long parameter
list. In that example, a call to an expression evaluator, the
parameter list is a set of arrays containing variable data. The
parameter list can be different in various parts of the application
(some but not all arrays different). But, within a given procedure
the parameter list is the same. In that case something like

.....
GoSub EvaluateExpression ' done 20 or 30 times in a procedure
.....

Exit Sub

EvaluateExpression:

Call ExpressionEval(Expr$,,,,,,,,,,,,,,,,,,,,,,,,)

Return

In this case, having 20 or 30 instances of Call ExpressionEval() would
eliminate the need for the GoSub. However, when you change
ExpressionEval parameters you have a pot full of places to screw up.
What's more, there is *zero* confusion about where the code is or what
it does. Likewise, other small fragments fit the same bill. No need
for confusion at all.

The point is, whether you agree with it or not, it's a good tool.

Now why don't you show me, in production code, that there are no good
places for GoSub. If you enjoy such games, have at it. In the
meantime I'll bet I can find someone who will argue, just as you are,
that there is never a need for GoTo. "Never a need" and "good tool
for the job" are two entirely different arguments.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jonathan Allen]

> In this case, having 20 or 30 instances of Call ExpressionEval() would
> eliminate the need for the GoSub. However, when you change
> ExpressionEval parameters you have a pot full of places to screw up.

Remember Cut-and -Paste? It has a friend called Search-and-Replace. It takes
about 5 seconds to highlight a line and tell the IDE to replace all
instances of it with the new version.

You are using laziness to justify the overhead of a GoSub call, which is
greater than that of a real function call in VB6.

*************

So again I challenge you to find a real-world method that is cleaner and
more efficient with a gosub. And this time post real code from a working
project this time, not just something you made up for the occasion.

--
Jonathan Allen

[Jason Thorn]

Hello all,

Sorry, I don't mean to get in between a perfectly good rant, however . . .
:)

Aren't Goto and Gosub analgous to the assembly unconditional jump and return
commands (mind you I don't know a whole lot about assembly)? I know thats
comparing apples to oranges, but it just goes to show that they have their
place. I wouldn't want to proclaim my self an expert, but personally I find
them usefull in situations (goto more than gosub.) Heck, even C++ has the
goto command. I recently had to write a routine, and I ended up using a
gosub for the first time since I wrote in Basic on my ATARI. Gosub is nice
because it maintains it's own call stack, unlike numerous goto commands, so
you can call it and return recursivly, and code within it can use variables
of procedure scope. Keeping all you data within the appropriate scope is
good OOP (at least encapsulation) isn't it? My personall opinion, by far not
the most important, is that just about evey programming construct has its
place. Whether or not it is used 'Properly' is up to the programmer . . .

Just some thoughts . . .
------------------------------------------------------------------
It's not the code that kills programs, it's the programmers :)



"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a7f2ee2@news.devx.com...
> > "Most"? I question your information. Can you cite?
>
> Unfortunately, it is only anecdotal. All of the programming teachers I
have
> had forbid any use Goto or Gosub (except assembly classes). Every
programmer
> I know personally also frowns on its use.
>
> --
> Jonathan Allen
>
> "When considering performance, one must rate accuracy over speed. No one
> cares how fast you can give the wrong answer." - Anonymous
>
>
> "Dan Barclay" <dbarclay@ih2000.net> wrote in message
> news:l3au7tgobp4uafuoub7iqbkhkeko8o8m7r@4ax.com...
> > On Sun, 4 Feb 2001 12:26:50 -0800, "Jonathan Allen"
> > <greywolfcs@bigfoot.com> wrote:
> >
> > >> Am I the only person in the world who actually likes GOSUB/RETURN?
> > >
> > >No, there are a few people still using them. However, most gave them up
> when
> > >QBasic was released.
> >
> > "Most"? I question your information. Can you cite?
> >
> > Dan
> > Language Stability is a *feature* I wish VB had!
> > (#6)
>
>

[Jonathan Allen]

> Aren't Goto and Gosub analgous to the assembly unconditional jump and
return
> commands (mind you I don't know a whole lot about assembly)? I know thats
> comparing apples to oranges, but it just goes to show that they have their
> place.

Pointers and other forms of raw memory access have their place as well.
However, their place is in systems programming, languages, not high level
languages meant for business apps.

There is a lot involved in implementing GoSub in VB.Net. It is no where near
as clean as the sub/return operations in assembly. Some of us don't think it
is worth it.

If you place the return point on the stack, you screw up the stack pointer
for referencing other variables. If there is an error, you have to manually
unwind the stack so that the standard error handlers can take over. If you
call functions from within a GoSub and an error occurs, then the CLR has to
figure out how to deal with the non-standard frame when building the stack
trace.

It is not impossible, just difficult and time consuming. MS has decided to
put its resources in making VB.Net itself better instead of supporting a
design that has real benefit other than acting as a macro.

--
Jonathan Allen

[Dan Barclay]

On Mon, 5 Feb 2001 21:14:52 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> In this case, having 20 or 30 instances of Call ExpressionEval() would
>> eliminate the need for the GoSub. However, when you change
>> ExpressionEval parameters you have a pot full of places to screw up.
>
>Remember Cut-and -Paste? It has a friend called Search-and-Replace. It takes
>about 5 seconds to highlight a line and tell the IDE to replace all
>instances of it with the new version.
>
>You are using laziness to justify the overhead of a GoSub call, which is
>greater than that of a real function call in VB6.

So, you would use a multi-line search/replace for code editing? Yea,
the example showed one line, but most GoSubs are more. Your logic is
weak here Jonathan.

Laziness, properly applied, is a good attribute for a programmer. It
leads to reusable code (assuming the environment doesn't get hosed)
and less duplicated code.

If you maintain code using search/replace for stuff like this... whew!

>*************
>
>So again I challenge you to find a real-world method that is cleaner and
>more efficient with a gosub. And this time post real code from a working
>project this time, not just something you made up for the occasion.

First, that was real code from a working project (though I didn't, and
won't, repeat the entire proc). Second, let's see code that shows
GoSub is useless? That's your contention, is it not?

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Dan Barclay]

On Mon, 5 Feb 2001 21:34:38 -0800, "Jason Thorn" <j_thorn@hotmail.com>
wrote:

>
>Aren't Goto and Gosub analgous to the assembly unconditional jump and return
>commands (mind you I don't know a whole lot about assembly)?

Goto is analogous to Jmp. GoSub/Return are analogous to Call/Ret.

>Just some thoughts . . .

on the right track. Yes, tools are tools.

>------------------------------------------------------------------
>It's not the code that kills programs, it's the programmers :)

LOL! Right on the money.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jason Thorn]

Ok, suggestions? Please excuse the HTML, I thought it would make things easier to read.Please note that I did at least comment the gosub appropriately :)( Yes I know there isn't an error handler yet :) )
Friend Sub RefreshColumns() Dim vDate As Date Dim oRs As ADODB.Recordset Dim sDescription As String Dim lItemCount As Long Dim lCol As Long Dim lLeft As Long Dim lRow As Long ' Turn the grid refresh off temporarily IsRedrawOn = False
' Call the Stored procedure that fetches event entries Set oRs = DbFunction("csp_getCalendarEvents", Null, m_oCal.StartDate, m_oCal.EndDate, m_oCal.CurrentOffice) With grdCalendar ' Store the left scroll position to restore it after we're done lLeft = .ScrollLeft ' Clear the grid Call .Clear(True) Call .Columns.Add("Names", , , , , True, , , , True) lRow = .Rows.Add(, "Totals") .Cells(lRow, 1).BackColor = vbButtonFace ' Begin with the start date vDate = m_oCal.StartDate ' and continue until we pass the end date Do Until vDate > m_oCal.EndDate ' If this day is a Weekend, and we are viewing Weekends, then add the column, Or . . . ' If this day is a Weekday, add a column If (m_bShowWeekends And ((Weekday(vDate) = vbSaturday) Or (Weekday(vDate) = vbSunday))) Or _ ((Weekday(vDate) <> vbSaturday) And (Weekday(vDate) <> vbSunday)) Then
' Go fecth the appropriate record data GoSub FetchNext ' Add a column for the day lCol = .Columns.Add(Fix(vDate), sDescription) .Cell(lRow, lCol).BackColor = vbButtonFace ..Cell(lRow, lCol).Text = IIf(lItemCount > 0, lItemCount, "No") & " Items Scheduled" lItemCount = 0 sDescription = vbNullString End If ' increment the day vDate = vDate + 1 Loop ' Refresh the data in the columns Call RefreshSchedules ..ScrollLeft = lLeft End With IsRedrawOn = TrueExit Sub
' Yeah Yeah, I know . . . GoSubs Suck' It just seemed better and cleaner to do' this here than to try and code it into' the loop itself.FetchNext: If oRs.State = adStateOpen Then If Not (oRs.EOF Or oRs.BOF) Then ' If we have a record for the current date, get the info If oRs!thisdate = vDate Then ' Get the description and item count information. If sDescription = vbNullString Then sDescription = oRs!Description & vbNullString Else sDescription = sDescription & vbCrLf & oRs!Description End If lItemCount = oRs!ItemCount + lItemCount oRs.MoveNext ' Check for more data on this date GoSub FetchNext Return ' Otherwise fetch the next record if the current record is ' prior to the date we are looking for. (This may be because ' we have weekend data, and we are not showing weekends on the calendar.) ElseIf oRs!thisdate < vDate Then oRs.MoveNext ' Call the routine again to get the right data GoSub FetchNext Return End If End If End If If sDescription = vbNullString Then sDescription = Format(vDate, "ddd\. m/d/yyyy") End IfReturn End Sub
"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message news:3a7f8d4f@news.devx.com...
> > In this case, having 20 or 30 instances of Call ExpressionEval() would
> > eliminate the need for the GoSub. However, when you change
> > ExpressionEval parameters you have a pot full of places to screw up.
>
> Remember Cut-and -Paste? It has a friend called Search-and-Replace. It takes
> about 5 seconds to highlight a line and tell the IDE to replace all
> instances of it with the new version.
>
> You are using laziness to justify the overhead of a GoSub call, which is
> greater than that of a real function call in VB6.
>
> *************
>
> So again I challenge you to find a real-world method that is cleaner and
> more efficient with a gosub. And this time post real code from a working
> project this time, not just something you made up for the occasion.
>
> --
> Jonathan Allen
>
>
>

[Jonathan Allen]

> Ok, suggestions?

Thanks for the challange, but it was too easy. Just pass the variables
ByRef.

NEXT!

******************************

Sub FetchNext (ByRef oRs As Recordset, _
ByRef vDate As Date, ByRef sDescription As String, lItemCount As Long)

If oRs.State = adStateOpen Then
If Not (oRs.EOF Or oRs.BOF) Then
' If we have a record for the current date, get the info
If oRs!thisdate = vDate Then
' Get the description and item count information.
If sDescription = vbNullString Then
sDescription = oRs!Description & vbNullString
Else
sDescription = sDescription & vbCrLf & oRs!Description
End If
lItemCount = oRs!ItemCount + lItemCount
oRs.MoveNext
' Check for more data on this date
Call FetchNext (oRs, vDate, sDescription, lItemCount)
Exit Sub
' Otherwise fetch the next record if the current record is
' prior to the date we are looking for. (This may be because
' we have weekend data, and we are not showing weekends on the
calendar.)
ElseIf oRs!thisdate < vDate Then
oRs.MoveNext
' Call the routine again to get the right data
Call FetchNext (oRs, vDate, sDescription, lItemCount)
Exit Sub
End If
End If
End If
If sDescription = vbNullString Then
sDescription = Format(vDate, "ddd\. m/d/yyyy")
End If
End Sub



--
Jonathan Allen

[Jonathan Allen]

> First, that was real code from a working project (though I didn't, and
> won't, repeat the entire proc).

Maybe it was, but it still didn't justify GoSub. If you want to use it too
justify adding C style Macros, I'm right behind you. That is what you are
using it for anyways.

> Second, let's see code that shows
> GoSub is useless? That's your contention, is it not?

As you very well know, you can't really prove something is useless. You can
only suggest it by empirical evidence. However, you can only prove something
is useful. Thus the burden of proof is on you by logical necessity.

--
Jonathan Allen

[Jason Thorn]

But why is this less overhead than a gosub, and why do I need a proc which
re-defines the same variables I have already declared, which will be used
only in this one place. It doesn't seem any more elegant, or any easier to
debug . . . Hence, no benefit.

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a7facaf@news.devx.com...
> > Ok, suggestions?
>
> Thanks for the challange, but it was too easy. Just pass the variables
> ByRef.
>
> NEXT!
>
> ******************************
>
> Sub FetchNext (ByRef oRs As Recordset, _
> ByRef vDate As Date, ByRef sDescription As String, lItemCount As Long)
>
> If oRs.State = adStateOpen Then
> If Not (oRs.EOF Or oRs.BOF) Then
> ' If we have a record for the current date, get the info
> If oRs!thisdate = vDate Then
> ' Get the description and item count information.
> If sDescription = vbNullString Then
> sDescription = oRs!Description & vbNullString
> Else
> sDescription = sDescription & vbCrLf & oRs!Description
> End If
> lItemCount = oRs!ItemCount + lItemCount
> oRs.MoveNext
> ' Check for more data on this date
> Call FetchNext (oRs, vDate, sDescription, lItemCount)
> Exit Sub
> ' Otherwise fetch the next record if the current record is
> ' prior to the date we are looking for. (This may be because
> ' we have weekend data, and we are not showing weekends on the
> calendar.)
> ElseIf oRs!thisdate < vDate Then
> oRs.MoveNext
> ' Call the routine again to get the right data
> Call FetchNext (oRs, vDate, sDescription, lItemCount)
> Exit Sub
> End If
> End If
> End If
> If sDescription = vbNullString Then
> sDescription = Format(vDate, "ddd\. m/d/yyyy")
> End If
> End Sub
>
>
>
> --
> Jonathan Allen
>
>

[Jonathan Allen]

> Sub FetchNext (ByRef oRs As Recordset, _
> ByRef vDate As Date, ByRef sDescription As String, lItemCount As Long)

Sorry, I made a mistake. Since you never use "Set oRS = ..." inside the sub,
you should be able to pick up a few cycles by using "ByVal oRs As
Recordset". If you don't know why that works, just ask.

--
Jonathan Allen

[Larry Serflaten]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote
>
> As you very well know, you can't really prove something is useless. You can
> only suggest it by empirical evidence. However, you can only prove something
> is useful. Thus the burden of proof is on you by logical necessity.

It seems you are grasping statements out of thin air, to support your own
opinions. For example, take a wet noodle, and try to use it to drive a screw
into a block of wood. No one can do it, therefore it is useless for that task.
To get around the empirical clause, you can measure the torque generated
when giving the noodle a turn, and you can measure the torque required to
turn the screw. When you find the noodle can not produce the required torque,
you have proven that it will not drive the screw into the wood, even if you never
touch the screw with the noodle.

Or, take a sheet of paper, and try to use it as an outer jacket against the cold.
Now that's useless.....

Suggesting that Gosub is not ever needed and so should be removed, removes
one option at the programmers disposal. It was only an option, so no one
should miss it right? Not so, just being an option does not suggest it should be
removed (Command() is another such option that should not be removed)

Yes, I have used Gosub, in one project, that I can recall. So I don't use it like
some others might, but that doesn't mean I think it should have been removed. I
am looking at .Net as something totally new, which is why I am not being very
vocal one way or another. But this post made it appear to me that you are
simply arguing for arguments sake, saying anything just to oppose those who
you want to oppose... Not a very friendly attitude, why is that?

LFS

[Ed Courtenay]

> You and some others around here claiming to be Master Programmers
> start talking about how stupid it is to use GoSub. Because you claim
> to know what you're doing, some people actually think you do. My bet
> is that there are more people lurking here who use GoSub. I use it,
> and I have the guts to admit it. It's a valuable tool.

Whoa! Down boy! Down boy! Claiming to be Master Programmers? I've been a
contract developer for a good many years now (10+) and I can honestly state
that every single institution I have developed for, where Coding Standards
were enforced (95% of them) *forbade* the use of GOSUB/RETURN and GOTO (with
the obvious exception of ON ERROR...); this is the real world experience of
myself and every other programmer I know (and I know a few...) I would
definately class myself as a Master Programmer (although I'm too modest to
state that in public ;-) and find the insinuation that simply because we
decry the use of this vile construct (in our opinions) we are newbies to the
game.

[Ed Courtenay]

Sad to say, but I don't think anyone will bite on this; I tried about a week
ago and just got insulted. Ho hum. But, if anyone wants to prove a point,
post some code...

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a7f7c25@news.devx.com...
> Lets play a game. Post a real-life, production grade method that uses a
> gosub and we will try to remove the need for the gosub.
>
> --
> Jonathan Allen

[James D. Foxall]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a7f8d4f@news.devx.com...
> > snip
> You are using laziness to justify the overhead of a GoSub call, which is
> greater than that of a real function call in VB6.

That's a stupid statement. I use GoSub <rarely>, but I still use it. I'm not
lazy. I spent a lot of time researching these things for a VB standards book
I wrote. Of course, the book essentially boils down to opinions and
philosophy, and there's plenty to argue about in it. One thing I found for
sure is you can't speak in absolutes like this (unless you want hate mail
<g>).

Here's what I wrote on GoSub, if you're interested:

***********
Refrain from using GoSub whenever possible.

The ability to use GoSub in code dates back to the early days of Basic, when
code was linear rather than procedural. GoSub allows you to create a
"pseudosubroutine." A GoSub <label> statement causes execution to jump to
the specified label, which must be in the same procedure as the GoSub
statement. A Return statement causes execution to return to the line
following the GoSub statement. GoSubs make the code difficult to read and
debug. With the advent of procedure-based, event-driven code, a GoSub is
rarely needed. If you find yourself writing a GoSub, ask yourself whether
the code that you branch to could be handled in-line within the procedure.
If not, determine whether it could be turned into a separate procedure. If
it can, chances are good that creating a separate procedure is a better
approach.

The one time GoSub really comes in handy is when the code in the
pseudosubroutine works on a large number of variables local to the
procedure. Under certain rare circumstances, the overhead and hassle of
passing many local variables to another routine make GoSub a better
proposition.
***************

When I say overhead, I'm not talking bits and bytes, as much as maintenance
issues.

While I STRONGLY advice against using GoSub, I don't go so far as to say
NEVER use it - that's just nuts. Good programmers find creative uses for all
tools. Just because you choose never to use it, doesn't mean that others
don't find value in it.

--

James D. Foxall
Microsoft Certified Solution Developer

[Sjoerd Verweij]

That's not the point. Demanding to prove a negative is a logical fallacy.

[Sjoerd Verweij]

> GoSub EvaluateExpression ' done 20 or 30 times in a procedure
> .....
> Exit Sub
> EvaluateExpression:
> Call ExpressionEval(Expr$,,,,,,,,,,,,,,,,,,,,,,,,)
> Return

Erm, Dan...

Type ExprData
...
End Type

ExpressionEval ExprData ' 20 or 30 times


> Now why don't you show me, in production code, that there are no good
> places for GoSub.

What's next, proving God does not exist?

[Dan Barclay]

On Tue, 6 Feb 2001 10:53:45 -0800, "Sjoerd Verweij"
<nospam.sjoerd@sjoerd.org> wrote:

>That's not the point. Demanding to prove a negative is a logical fallacy.

That's not the point either.

Hint: The point is that arguing "you can do with out that" when the
issue is "this feature is useful" is a logical fallacy.

Posting another logical fallacy in response was the original hint.
****. Have to explain everything.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Dan Barclay]

On Tue, 6 Feb 2001 10:55:32 -0800, "Sjoerd Verweij"
<nospam.sjoerd@sjoerd.org> wrote:

>> GoSub EvaluateExpression ' done 20 or 30 times in a procedure
>> .....
>> Exit Sub
>> EvaluateExpression:
>> Call ExpressionEval(Expr$,,,,,,,,,,,,,,,,,,,,,,,,)
>> Return
>
>Erm, Dan...
>
>Type ExprData
> ...
>End Type

Doesn't work. The parameter grouping is different depending on the
usage. What's more, some parameters are sometimes the same.

Don't you think I'd have thought of that??? Geeezzz. Duhhh... this is
an expression evaluator. I've written a line or two of code before.

Do you think VB programmers are dunces? It's a different language,
not a different world.

Dan

Language Stability is a *feature* I wish VB had!
(#6)

[Sjoerd Verweij]

> Hint: The point is that arguing "you can do with out that" when the
> issue is "this feature is useful" is a logical fallacy.

Ah, sorry, I wasn't referring to that. I was referring to "Post some code
that shows it isn't useful". I'm opposed to GoSub, but more out of an
"please, other people (me) have to review this and chances that you know how
to use it properly are virtually nil, so don't" -- the wonderful things that
working with chimp contractors does to your attitude. In very rare cases, it
is a workable solution, but never the best.

On a sidenote, GoTo is much, much worse. Jumping out of a loop? Wow, never
had a refcount leak because it was in a With block I wager? Exit X is just
as bad. I'm just really, really, really fond of linear execution paths,
single point of exit and single point of entry. It makes debugging so much
easier.

[Carlos Novela]

I hate VB.NOT it looks like garbage. I want VB7 NOW!

"James D. Foxall" <jamesf@tigerpawsoftware.com> wrote:
>"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
>news:3a7f8d4f@news.devx.com...
>> > snip
>> You are using laziness to justify the overhead of a GoSub call, which
is
>> greater than that of a real function call in VB6.
>
>That's a stupid statement. I use GoSub <rarely>, but I still use it. I'm
not
>lazy. I spent a lot of time researching these things for a VB standards
book
>I wrote. Of course, the book essentially boils down to opinions and
>philosophy, and there's plenty to argue about in it. One thing I found for
>sure is you can't speak in absolutes like this (unless you want hate mail
><g>).
>
>Here's what I wrote on GoSub, if you're interested:
>
>***********
>Refrain from using GoSub whenever possible.
>
>The ability to use GoSub in code dates back to the early days of Basic,
when
>code was linear rather than procedural. GoSub allows you to create a
>"pseudosubroutine." A GoSub <label> statement causes execution to jump to
>the specified label, which must be in the same procedure as the GoSub
>statement. A Return statement causes execution to return to the line
>following the GoSub statement. GoSubs make the code difficult to read and
>debug. With the advent of procedure-based, event-driven code, a GoSub is
>rarely needed. If you find yourself writing a GoSub, ask yourself whether
>the code that you branch to could be handled in-line within the procedure.
>If not, determine whether it could be turned into a separate procedure.
If
>it can, chances are good that creating a separate procedure is a better
>approach.
>
>The one time GoSub really comes in handy is when the code in the
>pseudosubroutine works on a large number of variables local to the
>procedure. Under certain rare circumstances, the overhead and hassle of
>passing many local variables to another routine make GoSub a better
>proposition.
>***************
>
>When I say overhead, I'm not talking bits and bytes, as much as maintenance
>issues.
>
>While I STRONGLY advice against using GoSub, I don't go so far as to say
>NEVER use it - that's just nuts. Good programmers find creative uses for
all
>tools. Just because you choose never to use it, doesn't mean that others
>don't find value in it.
>
>--
>
>James D. Foxall
>Microsoft Certified Solution Developer
>
>
>

[Sjoerd Verweij]

> Don't you think I'd have thought of that??? Geeezzz. Duhhh... this is
> an expression evaluator. I've written a line or two of code before.

Okay, maybe I should post/mail the evaluator I wrote in VB.NET then? There's
no need for all that.

[Sjoerd Verweij]

> I hate VB.NOT it looks like garbage. I want VB7 NOW!

Thank you for this constructive comment. Really, it's so refreshing.

[Dan Barclay]

On Tue, 6 Feb 2001 11:32:54 -0800, "Sjoerd Verweij"
<nospam.sjoerd@sjoerd.org> wrote:

>> Hint: The point is that arguing "you can do with out that" when the
>> issue is "this feature is useful" is a logical fallacy.
>
>Ah, sorry, I wasn't referring to that. I was referring to "Post some code
>that shows it isn't useful".

I wasn't referring to that either. "Post some code that shows it
isn't useful" was the answer to that. Anyway...

>I'm opposed to GoSub, but more out of an
>"please, other people (me) have to review this and chances that you know how
>to use it properly are virtually nil, so don't" --

If they can't use it properly get rid of them, show them how, or
forbid *them* to use it. No need to get rid of a good tool. Perhaps
what you're working on has little need of it.

Heck, I seldom need databases. From my perspective I guess you could
get rid of ADO. Does that make any sense?

>the wonderful things that
>working with chimp contractors does to your attitude. In very rare cases, it
>is a workable solution, but never the best.
>
>On a sidenote, GoTo is much, much worse. Jumping out of a loop?

You bet. When the alternative is convoluted Endx's from several
structures deep it's much more readable.

>Wow, never
>had a refcount leak because it was in a With block I wager?

Never jumped out of a With block, or had a need to. In fact I keep
With blocks very small... they're dangerous if you loose sight of the
scope IMHO.

> Exit X is just
>as bad. I'm just really, really, really fond of linear execution paths,
>single point of exit and single point of entry. It makes debugging so much
>easier.

I've fond of linear execution paths as well, with well placed calls.
Good hammer, but everything's not a nail.

Sounds like you're just the structure zealot to talk to Jonathan. He
seems to think GoTo's are alright but GoSubs aren't. At least you're
consistent (seriously <g>).

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Sjoerd Verweij]

> >Ah, sorry, I wasn't referring to that. I was referring to "Post some code
> >that shows it isn't useful".
> I wasn't referring to that either. "Post some code that shows it
> isn't useful" was the answer to that. Anyway...

Forgetting the order in which the statements were made, "post some code that
shows it isn't useful" still is equivalent to "prove that God does not
exist" and a logical fallacy.

But anyway.

> If they can't use it properly get rid of them, show them how, or
> forbid *them* to use it. No need to get rid of a good tool. Perhaps
> what you're working on has little need of it.

Not really. I still wish for nested Sub/Functions. Darnit, if something as
ancient as Pascal can have it!!!

> You bet. When the alternative is convoluted Endx's from several
> structures deep it's much more readable.

Not to me, but maybe I'm a freak. I have coded like this for years. Example:

Do While X
...
For I = 1 To N
...
Do While Y
...
Goto L1
...
Loop
Next
Loop
L1:

has always been this in my code:

Do While X And StillOk
I = 1
Do While I < N And StillOk
Do While Y And StillOk
StillOk = False
Loop
If StillOk Then I = I + 1
Loop
Loop

Of course, it ties in tightly with how I do error handling. I *never* use On
Error Goto. It's always something like

On Error Resume Next
DoSomeThing
If Err.Number > 0 Then StillOk = False
On Error Goto 0

(By the by, this is of course why I don't mind the transition so much. At
least I don't have to worry about structure logic changing along with
everything else!)

> Never jumped out of a With block, or had a need to. In fact I keep
> With blocks very small... they're dangerous if you loose sight of the
> scope IMHO.

Ah. Should've known you're smarter than that. Still, with On Error Goto...

> Sounds like you're just the structure zealot to talk to Jonathan. He
> seems to think GoTo's are alright but GoSubs aren't. At least you're
> consistent (seriously <g>).

Yes, his stance in this is odd to say the least.

[Dan Barclay]

On Tue, 6 Feb 2001 11:38:00 -0800, "Sjoerd Verweij"
<nospam.sjoerd@sjoerd.org> wrote:

>> Don't you think I'd have thought of that??? Geeezzz. Duhhh... this is
>> an expression evaluator. I've written a line or two of code before.
>
>Okay, maybe I should post/mail the evaluator I wrote in VB.NET then? There's
>no need for all that.

No need for all what? The parameters? I use parameters because I
want to influence the scope of variables evaluator works on. I want
to do that by having them be a parameter list. One EE, useable for
logical or value expressions. Variable scope manageable with
parameter lists.

The point, however, is not an EE. The point is that the code is
cleaner and more easily maintained if you don't proliferate long
parameter lists unnecessarily.

It's not just the trees, there is a forest here.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Karl E. Peterson]

Hi Dan!

> Heck, I seldom need databases. From my perspective I guess you could
> get rid of ADO. Does that make any sense?

Now *there* is a solution in search of some "positive feedback"! I could certainly
provide Microsoft with all kinds of warm fuzzies for a decision like this.
Yessiree!!! :-)

Later... Karl
--
http://www.mvps.org/vb/rants/vfred.htm


PS -- If you ask Bill Vaughn, I suspect he'll tell you they already got rid of ADO.
<g>

[Karl E. Peterson]

"Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
news:3a80533c$1@news.devx.com...
> > I hate VB.NOT it looks like garbage. I want VB7 NOW!
>
> Thank you for this constructive comment. Really, it's so refreshing.

LOL! Yeah, why bother reading the other 10K posts, huh?
--
http://www.mvps.org/vb

[Sjoerd Verweij]

Karl,

Are you actually going to contribute *anything* to the thread other than
none too oblique ad hominems and generic advocacy whining?

I hope so.

Sjoerd

[Sjoerd Verweij]

> No need for all what? The parameters? I use parameters because I
> want to influence the scope of variables evaluator works on. I want
> to do that by having them be a parameter list. One EE, useable for
> logical or value expressions. Variable scope manageable with
> parameter lists.

And it can be done just as well without a humonguous parameter list by a
different approach to the problem.

[Karl E. Peterson]

Hi Sjoerd --

> Are you actually going to contribute *anything* to the thread other than
> none too oblique ad hominems and generic advocacy whining?

Huh? That should've been entirely oblique, or else I was far too clear! <g> It
probably should've been a private comment though, as it touches on a conversation Dan
and I have been having with a particular language designer.

> I hope so.

I really have little more to add to this one. The point has been made clearly, by me
and others. Do you really hope for more of the same?

Thanks... Karl
--
http://www.mvps.org/vb

[Sjoerd Verweij]

Karl,

> > I hope so.
> I really have little more to add to this one.

Then please stop interjecting with playground-grade flamebait. I swear, one
would need a Decimal to store your S/N ratio of late. If you are aiming for
being ignored out of hand, you're doing one **** of a job.

Thanks
Sjoerd

[Karl E. Peterson]

S/N??? As opposed to your postulating a proof for god? <LOL>
--
http://www.mvps.org/vb


"Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
news:3a8074c6$1@news.devx.com...
> Karl,
>
> > > I hope so.
> > I really have little more to add to this one.
>
> Then please stop interjecting with playground-grade flamebait. I swear, one
> would need a Decimal to store your S/N ratio of late. If you are aiming for
> being ignored out of hand, you're doing one **** of a job.
>
> Thanks
> Sjoerd
>
>

[Sjoerd Verweij]

> S/N??? As opposed to your postulating a proof for god? <LOL>

*woosh*

Thank you for proving my point.

[Mike Mitchell]

On Mon, 5 Feb 2001 14:37:54 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> "Most"? I question your information. Can you cite?
>
>Unfortunately, it is only anecdotal. All of the programming teachers I have
>had forbid any use Goto or Gosub (except assembly classes). Every programmer
>I know personally also frowns on its use.

A carpenter also has a hammer in his toolbox, but he will mostly not
use it and will caution his apprentice against using it. Mostly, he
will use the plane, spokeshave, bradawl, screwdriver, chisel and
sandpaper. However, sometimes, every once in a while, something just
has to be hit home. And then the hammer is just the right tool for the
job. The plane is weightier. Probably the spokeshave would also do as
a hammer. But when you need a hammer, nothing much else is really
quite so suited to hammering.

MM

[Mike Mitchell]

My two penny'orth on the continuing saga of GoSub? Jonathan and Sjoerd
and others who flatly refuse to even acknowledge the tacit presence of
GoSub are language snobs. This is not an insult. I am not saying that
they are personally snobs, but they are language snobs, as in
'computer languages'. This phenomenon is perceived as the same kind of
inward fear experienced by real snobs when confronted with something
they feel they cannot control. Thus, they find succour in ridicule,
denial, and superiority. As they are not able to argue the logical
points under discussion, as to do so would in their eyes reduce
themselves down to the level of their opponents, their only defence is
to suppress, deny, and ultimately ignore.

However,a good smack in the face with a wet catfish usually works
wonders with these people!

MM

[James D. Foxall]

"Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
news:3a8051b4$1@news.devx.com...
> On a sidenote, GoTo is much, much worse. Jumping out of a loop? Wow, never
> had a refcount leak because it was in a With block I wager? Exit X is just
> as bad. I'm just really, really, really fond of linear execution paths,
> single point of exit and single point of entry. It makes debugging so much
> easier.
>

Hi Sjoerd,

I'm curious as to how you accomplish single exit points in VB5/6 without
using GoTos?

--

James D. Foxall
Microsoft Certified Solution Developer

[Jonathan Wood]

James,

> I'm curious as to how you accomplish single exit points in VB5/6 without
> using GoTos?

Correct use of loop structures.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Sjoerd Verweij]

> Jonathan and Sjoerd
> and others who flatly refuse to even acknowledge the tacit presence of
> GoSub are language snobs.

Since my stance is obviously unclear, let me try and summarize it. Gosub has
never bothered my personal coding. If I were to work alone on projects, or
could control every stage of coding I wouldn't mind having it around at all.

To extrapolate on your analogy: imagine me (and from what I understand,
Johnathan) as being carpenters that have to fix a house because the owner
has dropped straight through the floor for the seventh time. When you once
again ascertain that the problem stems from retarded apprentices inserting
bolts by way of a pneumatic hammer, you might feel strongly against said
apprentices having access to one. Especially since you know their toolbox
contains wrenches as well.

But sure, a pneumatic hammer comes in handy sometimes.

Speaking for myself, I am a total, utter, anal-retentive coding style snob.
I code the way I do because its the only way I've seen in my code or anyone
elses that scales well in a team environment.

How about a project-level "Option Gosub Off" :-)

[Jonathan Wood]

Mike,

> My two penny'orth on the continuing saga of GoSub? Jonathan and Sjoerd
> and others who flatly refuse to even acknowledge the tacit presence of
> GoSub are language snobs.

And which Jonathan would you be referring to?

I expressed an opinion about language constructs and have also described why
I will not miss GoSub. If you were referring to me, then I'd hope you'd
demonstrate how I was wrong instead of just calling names.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jay Glynn]

Dan,


> No, they aren't. Crappy code is a source of problems and confusion.
> To think that you eliminate problems by removing tools is silly.

Take away the gun, and you can't shoot yourself.

> If you take an idiot and have him reproduce the same startup/cleanup
> code fragments within 20 Cases of a 30 Case Select, you've got a
> boatload of problems. Sometimes the way to eliminate that is to wrap
> those fragments in a procedure. Other times the best way is to put
> the fragments in a labeled procedure and GoSub/Return.

The best way is to design so that neither becomes an issue.

> GoTo's are quite useful for jumping *cleanly* out of deeply nested
> flow control (Do/For/etc). You can *greatly* increase readability...
> or you can screw it up badly. Likewise, you can use Exit ThisAndThat
> to work your way out and have it readable, or screwed up badly.

Again, good design, this never becomes an issue.

> *Anything* you do in an app of any significant size can be very
> dangerous. Team setting or not, bad code is bad code. If you have a
> team that doesn't know how to use GoSubs or GoTo's effectively, teach
> them or forbid them. I submit that if you can't teach them how to use
> the tools correctly you may need to look for another team. Don't,
> however, think you know enough about Basic programming to presume to
> tell the rest of the world *they* shouldn't use them.

First of all, I never told YOU to use or not to use go-anything. I could not
care less if you do or do not since at present I don't have to maintain your
code. I currently work with a top notch team of developers, and the standard
of not using goto or gosub is a team decision, not mine. If you read the
post you will notice that I said if used properly they can be useful. The
problem is that a lot of developers don't use them properly, and misuse of
either can lead to ugly things. Yes, if someone writes bad code, it doesn't
matter what the toolset is, but I have better things to do then to worry
about gosub and goto.

And I submit to you that you shouldn't be such an arrogant sob that you
should tell me that I should use them.

--
Jay Glynn
Introducing .NET
ISBN: 1861004893
Wrox Press Ltd.

[Jason Thorn]

"Jay Glynn" <jay_glynn@agla.com> wrote in message
news:3a809d0d$1@news.devx.com...
> Dan,
>
>
> > No, they aren't. Crappy code is a source of problems and confusion.
> > To think that you eliminate problems by removing tools is silly.
>
> Take away the gun, and you can't shoot yourself.

C'mon, bad code can just as easily be written without a gosub / goto (I
think we have all learned this through trial and error, not just having to
maintain someone else's code.) . . . Why don't we take away the computer
too.

Better yet, why don't we just card people before they write code, they could
use IQ cards instead of ID cards. If their reference-count isn't high
enough, they aren't allowed to code :) Wouldn't that be the ultimate 'Smart
Card'

[Dan Barclay]

On Tue, 6 Feb 2001 19:07:58 -0600, "Jay Glynn" <jay_glynn@agla.com>
wrote:

>> No, they aren't. Crappy code is a source of problems and confusion.
>> To think that you eliminate problems by removing tools is silly.
>
>Take away the gun, and you can't shoot yourself.

Or kill food very easily. Guess it's back to sharp sticks.

> > If you take an idiot and have him reproduce the same startup/cleanup
>> code fragments within 20 Cases of a 30 Case Select, you've got a
>> boatload of problems. Sometimes the way to eliminate that is to wrap
>> those fragments in a procedure. Other times the best way is to put
>> the fragments in a labeled procedure and GoSub/Return.
>
>The best way is to design so that neither becomes an issue.

"good design" is a matter of opinion. I've seen code that the metrics
say is wonderful. You'd go nuts following operations through it.
Beauty is in the eye of the beholder, whether that matches what you
were taught or not.

>> GoTo's are quite useful for jumping *cleanly* out of deeply nested
>> flow control (Do/For/etc). You can *greatly* increase readability...
>> or you can screw it up badly. Likewise, you can use Exit ThisAndThat
>> to work your way out and have it readable, or screwed up badly.
>
>Again, good design, this never becomes an issue.

See above.

>> *Anything* you do in an app of any significant size can be very
>> dangerous. Team setting or not, bad code is bad code. If you have a
>> team that doesn't know how to use GoSubs or GoTo's effectively, teach
>> them or forbid them. I submit that if you can't teach them how to use
>> the tools correctly you may need to look for another team. Don't,
>> however, think you know enough about Basic programming to presume to
>> tell the rest of the world *they* shouldn't use them.
>
>First of all, I never told YOU to use or not to use go-anything. I could not
>care less if you do or do not since at present I don't have to maintain your
>code.

Those who insist (or support) that it be removed from the language are
doing exactly that. Perhaps I misread your intent?

>I currently work with a top notch team of developers, and the standard
>of not using goto or gosub is a team decision, not mine. If you read the
>post you will notice that I said if used properly they can be useful. The
>problem is that a lot of developers don't use them properly, and misuse of
>either can lead to ugly things. Yes, if someone writes bad code, it doesn't
>matter what the toolset is,

Exactly.

>but I have better things to do then to worry
>about gosub and goto.

The point about gosub and goto is that the next time they may very
well change something you *do* care about. A language subject to
arbitrary changes is a field of quicksand. I hope you're not the next
to step on a soft spot. You can't tell the firm ground from the mush
here.

>And I submit to you that you shouldn't be such an arrogant sob that you
>should tell me that I should use them.

I'm not telling you that you *should* use them. I don't know your
code. If I said something else it was unintended (or misunderstood).
I am responding to the arrogant sob's that claim gosub should never be
used.

What I'm telling you is that you should consider every tool in the
toolbox and *then* make that decision. I may be wrong, but I think
we're in agreement on that.

FWIW, Gosub is just one *symptom* of the problem I'm concerned about.
A visible one, but one that clearly illustrates the problem here.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Dan Barclay]

On Tue, 6 Feb 2001 17:01:52 -0600, "James D. Foxall"
<jamesf@tigerpawsoftware.com> wrote:

>"Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
>news:3a8051b4$1@news.devx.com...
>> On a sidenote, GoTo is much, much worse. Jumping out of a loop? Wow, never
>> had a refcount leak because it was in a With block I wager? Exit X is just
>> as bad. I'm just really, really, really fond of linear execution paths,
>> single point of exit and single point of entry. It makes debugging so much
>> easier.
>>
>
>Hi Sjoerd,
>
>I'm curious as to how you accomplish single exit points in VB5/6 without
>using GoTos?

I think it was he who posted a fragment earlier (could be wrong).
Anyhow, in that fragment he used flags to force loop exits to back his
way out. Hard to read sometimes, but it can be done.

You *can* do without damned near anything in the language.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jay Glynn]

--
Jay Glynn
Introducing .NET
ISBN: 1861004893
Wrox Press Ltd.


> "good design" is a matter of opinion. I've seen code that the metrics
> say is wonderful. You'd go nuts following operations through it.
> Beauty is in the eye of the beholder, whether that matches what you
> were taught or not.

I think that's what I said.

> >First of all, I never told YOU to use or not to use go-anything. I could
not
> >care less if you do or do not since at present I don't have to maintain
your
> >code.
>
> Those who insist (or support) that it be removed from the language are
> doing exactly that. Perhaps I misread your intent?
>

I said I have no use for it. I don't really care if it's in the language or
not. There is something to be said for language cleansing, however I don't
know how that should be done, and I'm not about to open that can-o-worms.

>
> What I'm telling you is that you should consider every tool in the
> toolbox and *then* make that decision. I may be wrong, but I think
> we're in agreement on that.

Yes we are. I decide one way, you the other.

> FWIW, Gosub is just one *symptom* of the problem I'm concerned about.
> A visible one, but one that clearly illustrates the problem here.

Again I point to language cleansing. Is it needed, how do you do it, etc
etc. Lot;s of questions. I think it is needed, and has been needed for a
long time. The environment that VB runs in has changed dramtically over the
years (Win 3.0 and dos to Win2k), can we really expect the language to
remain stable through that? Should I be using the same VB that I was 6 or 7
years ago? I don't thinkthe comparison to C is fair. It's apples and
oranges. VB was never intended to be the same type of language that C or
even C++ is. You do have the MFC - ATL issues there. There was a simple
migration path. now wasn't it. I guess I have become numb to stability
issues long ago. You can argue that language stability should be there now
and always, I just don't know how realistic that is in the current times.

[Jay Glynn]

Karl,

> S/N??? As opposed to your postulating a proof for god? <LOL>

That would be God to you...

[William Cleveland]

Sjoerd Verweij wrote:
>
> On a sidenote, GoTo is much, much worse. Jumping out of a loop? Wow, never
> had a refcount leak because it was in a With block I wager? Exit X is just
> as bad. I'm just really, really, really fond of linear execution paths,
> single point of exit and single point of entry. It makes debugging so much
> easier.

I'm kind of the opposite, here. I'm more fond of keeping code blocks
from getting too deep; I'll frequently have subroutines where the
first few lines are conditional exit subs / exit functions.

If the objection to exiting in the middle is that it's hard to see
(this is the only objection I've ever heard), and you might not
realise that the code might not get to the end, maybe the editor ought
to do something extra to highlight these statements (reverse-color,
underlined, etc.).

Bill

[Jonathan Allen]

> Heck, I seldom need databases. From my perspective I guess you could
> get rid of ADO. Does that make any sense?
>

They are not getting rid of GoSub, because VB.Net never had it to begin
with. They are simply refusing to add it.

--
Jonathan Allen

[Joe \Nuke Me Xemu\ Foster]

"Jonathan Wood" <jwood@softcircuits.com> wrote in message <news:3a8089e2@news.devx.com>...

> James,
>
> > I'm curious as to how you accomplish single exit points in VB5/6 without
> > using GoTos?
>
> Correct use of loop structures.

And more than enough boolean checks to make your eyes cross. The link I
posted the other day does address this. Part of the problem is, people
can and do get used to almost anything, including migraine-inducing
circumlocutions in their code. However, if chimp contractors can't use
GoTo properly, what in the world makes you think they'll get boolean
logic right?

--
Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Mike Mitchell]

On Wed, 7 Feb 2001 08:02:52 -0800, "Michael \(michka\) Kaplan"
<former_mvp@spamfree.trigeminal.nospam.com> wrote:

>He meant the stupid Jonathan, which is not you. HTH! :-)
>
>--
>MichKa

Jonathan, I think you got your answer!

MM

[Karl E. Peterson]

Hi Jay --

> > S/N??? As opposed to your postulating a proof for god? <LOL>
>
> That would be God to you...

Oh sure, get specific. She'll appreciate the correction, I'm sure.

Later... Karl
--
http://www.mvps.org/vb

[Sjoerd Verweij]

> I'm kind of the opposite, here. I'm more fond of keeping code blocks
> from getting too deep; I'll frequently have subroutines where the
> first few lines are conditional exit subs / exit functions.

On the first few lines, I really don't have all that many objections.

> If the objection to exiting in the middle is that it's hard to see
> (this is the only objection I've ever heard),

- Hard to see
- Makes the flow opaque
- Risk of bugs when cleanup code is inside the struct you bail out of
- Known bug in VB6 when used from within a With

[Karl E. Peterson]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a81b854@news.devx.com...
> > Heck, I seldom need databases. From my perspective I guess you could
> > get rid of ADO. Does that make any sense?
>
> They are not getting rid of GoSub, because VB.Net never had it to begin
> with. They are simply refusing to add it.

Look Jonathan, either it's VB or it isn't. Sounds like you're in the "IS NOT" camp?
Otherwise, your position is, well, I guess characteristically schizophrenic.

Thanks... Karl
--
http://www.mvps.org/vb

[Sjoerd Verweij]

> I think it was he who posted a fragment earlier (could be wrong).
> Anyhow, in that fragment he used flags to force loop exits to back his
> way out. Hard to read sometimes, but it can be done.

It's a matter of taste.

Do While Not CustomerEOF And Not ErrorOccurred

instantly makes it clear under what conditions this loop will end. Much
easier to read than having to scroll down to find one or more If EOF Then
Exit Do, let alone where you expect errors to be thrown if you use On Error
Goto.

[Sjoerd Verweij]

> However, if chimp contractors can't use
> GoTo properly, what in the world makes you think they'll get boolean
> logic right?

They won't -- but it makes it easier to debug their cruft IMHO.

[Sjoerd Verweij]

> And it is your contention that the approach that is ~Sjoerd is in some way
> inferior?

No.

> It still does not prove that it is not a useful tool in the right hands.

That's not my point, and if I gave that impression, I'm sorry.

- You don't need it
- Not using it creates more structured code (okay, this is subjective)
- Not having it is a good thing for bad programmers (okay, this is
subjective)

[William Cleveland]

"Karl E. Peterson" wrote:
>
> Look Jonathan, either it's VB or it isn't. Sounds like you're in the "IS NOT" camp?
> Otherwise, your position is, well, I guess characteristically schizophrenic.
>
I don't think it's VB, and I'm happy about that. VB is a big turd. I
seem to be the only one with that opinion, though.

Bill

[William Cleveland]

Sjoerd Verweij wrote:
>
> It's a matter of taste.
>
> Do While Not CustomerEOF And Not ErrorOccurred
>
> instantly makes it clear under what conditions this loop will end.

Not as clear, however, as

Do Until CustomerEOF Or ErrorOccurred



Bill

[William Cleveland]

Sjoerd Verweij wrote:
>
> > I'm kind of the opposite, here. I'm more fond of keeping code blocks
> > from getting too deep; I'll frequently have subroutines where the
> > first few lines are conditional exit subs / exit functions.
>
> On the first few lines, I really don't have all that many objections.
>
> > If the objection to exiting in the middle is that it's hard to see
> > (this is the only objection I've ever heard),
>
> - Hard to see
> - Makes the flow opaque
> - Risk of bugs when cleanup code is inside the struct you bail out of
> - Known bug in VB6 when used from within a With

I didn't know about the With bug; I'll have to keep that in mind.
The first one could be addressed by the editor (although it isn't,
currently).

As for your second and third objections, it seems to me that these
are just illustrating why doing thing right is important. It
doesn't change the answer in disputes as to what the right way is.

I had the same thing come up with one of my coworkers (the only one
who actually works on the same projects I do), when we disagreed
about whether "If bDoSomething Then" or "If bDoSomething = True Then"
was better (I prefer the first). The same thing came up in some
PostScript code of hers that I was reviewing (PostScript has a really
awkward if structure). She said that she could see why I had the
opinion I did in VB, but surely I had to think her way was right in
PostScript, because it was so much harder to see what was going on
there. My response was that that's why it's more important to do it
my way.

Bill

[Karl E. Peterson]

"William Cleveland" <WCleveland@Mediaone.Net> wrote in message
news:3A81DB00.DD02D72B@Mediaone.Net...
> "Karl E. Peterson" wrote:
> >
> > Look Jonathan, either it's VB or it isn't. Sounds like you're in the "IS NOT"
camp?
> > Otherwise, your position is, well, I guess characteristically schizophrenic.
> >
> I don't think it's VB, and I'm happy about that. VB is a big turd. I
> seem to be the only one with that opinion, though.

Which one?

Later... Karl
--
http://www.mvps.org/vb

[Jonathan Allen]

> Look Jonathan, either it's VB or it isn't. Sounds like you're in the "IS
NOT" camp?

Yes and no. I acknowledge it is not VB, but I refuse to join the "IS NOT"
camp because I don't agree with their position on most issues.

--
Jonathan Allen

[William Cleveland]

"Karl E. Peterson" wrote:
>
> "William Cleveland" <WCleveland@Mediaone.Net> wrote in message
> news:3A81DB00.DD02D72B@Mediaone.Net...
> > "Karl E. Peterson" wrote:
> > >
> > > Look Jonathan, either it's VB or it isn't. Sounds like you're in the "IS NOT"
> camp?
> > > Otherwise, your position is, well, I guess characteristically schizophrenic.
> > >
> > I don't think it's VB, and I'm happy about that. VB is a big turd. I
> > seem to be the only one with that opinion, though.
>
> Which one?
>
That VB is a big turd and that I'm happy it's being killed are pretty
much the same opinion, and the one I meant. That VB.Net isn't VB has
been said by quite a few people.

Bill

[Jason Kaczor]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote:
>
>Yes and no. I acknowledge it is not VB, but I refuse to join the "IS NOT"
>camp because I don't agree with their position on most issues.

I think we need a third faction in this war.

WILMA.NET (Married to Visual Fred)

I can take my new friend Wilma to all the fancy new clubs, but I still have
the wife at home (VB6), plenty of legacy support issues there...

It begs the question... is it still legal?

>--
>Jonathan Allen

Regards
Jason Kaczor

[James D. Foxall]

What?

You're kidding me right? This sounds like a nightmare...

--

James D. Foxall
Microsoft Certified Solution Developer

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3a8089e2@news.devx.com...
> James,
>
> > I'm curious as to how you accomplish single exit points in VB5/6 without
> > using GoTos?
>
> Correct use of loop structures.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>

[James D. Foxall]

You're right, you technically can do without anything, such as Option Strict
or even Option Explicit. Doesn't mean we want to or it would be the best.

In this case, I'd say GoTo is a better solution. All that flag setting gets
too **** ugly and prone to error.

--

James D. Foxall
Microsoft Certified Solution Developer


"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:bgb18tkkd0lqq917bul8i83fhpsjd64maq@4ax.com...
> On Tue, 6 Feb 2001 17:01:52 -0600, "James D. Foxall"
> <jamesf@tigerpawsoftware.com> wrote:
>
> >"Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
> >news:3a8051b4$1@news.devx.com...
> >> On a sidenote, GoTo is much, much worse. Jumping out of a loop? Wow,
never
> >> had a refcount leak because it was in a With block I wager? Exit X is
just
> >> as bad. I'm just really, really, really fond of linear execution paths,
> >> single point of exit and single point of entry. It makes debugging so
much
> >> easier.
> >>
> >
> >Hi Sjoerd,
> >
> >I'm curious as to how you accomplish single exit points in VB5/6 without
> >using GoTos?
>
> I think it was he who posted a fragment earlier (could be wrong).
> Anyhow, in that fragment he used flags to force loop exits to back his
> way out. Hard to read sometimes, but it can be done.
>
> You *can* do without damned near anything in the language.
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Sjoerd Verweij]

> You're kidding me right? This sounds like a nightmare...

Not at all on both counts.

[Sjoerd Verweij]

> In this case, I'd say GoTo is a better solution. All that flag setting
gets
> too **** ugly and prone to error.

I'd say the bugs you might have with flags are a darned sight less ugly than
the ones you might have with GoTo.

[Sjoerd Verweij]

> > Do While Not CustomerEOF And Not ErrorOccurred

> Not as clear, however, as
> Do Until CustomerEOF Or ErrorOccurred

I never use Until. I could rant on about interprative distinction and
consistency, but mostly it's taste.

[Sjoerd Verweij]

> "If bDoSomething Then" or "If bDoSomething = True Then"
> (I prefer the first).

Me too. If "= True" makes it easier to understand, you should change the
variable name.

[Karl E. Peterson]

Heh, silly boy, you haven't shown the slightest inkling of *understanding* the
issues -- no one's looking for your agreement with them. <g> (And, frankly, I'm
quite happy with your "camp of choice." Friends like you, and all that, eh? ;-)
--
http://www.mvps.org/vb


"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a8203ef@news.devx.com...
> > Look Jonathan, either it's VB or it isn't. Sounds like you're in the "IS
> NOT" camp?
>
> Yes and no. I acknowledge it is not VB, but I refuse to join the "IS NOT"
> camp because I don't agree with their position on most issues.
>
> --
> Jonathan Allen
>
>
>

[Dan Barclay]

On Thu, 8 Feb 2001 09:31:38 -0600, "James D. Foxall"
<jamesf@tigerpawsoftware.com> wrote:

>You're right, you technically can do without anything, such as Option Strict
>or even Option Explicit. Doesn't mean we want to or it would be the best.
>
>In this case, I'd say GoTo is a better solution. All that flag setting gets
>too **** ugly and prone to error.

Bingo.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Dan Barclay]

On Thu, 8 Feb 2001 10:56:55 -0800, "Sjoerd Verweij"
<nospam.sjoerd@sjoerd.org> wrote:

>> In this case, I'd say GoTo is a better solution. All that flag setting
>gets
>> too **** ugly and prone to error.
>
>I'd say the bugs you might have with flags are a darned sight less ugly than
>the ones you might have with GoTo.

Sometimes true, sometimes not. It's nice that we have a choice, then,
isn't it.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Mark Burns]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:3a82f482$1@news.devx.com...
> Heh, silly boy, you haven't shown the slightest inkling of *understanding*
the
> issues -- no one's looking for your agreement with them. <g>

Well...actually, to be completely fair, Jonathan *has* indeed shown an
inkling or two of understanding, he's just proving recalcitrant/reticent in
acknowedging the importance/severity/impact of the problems in the Real
World (where that #2 group is important and the opinion of the #1 group does
not rule the day more often than it does).

> (And, frankly, I'm
> quite happy with your "camp of choice." Friends like you, and all that,
eh? ;-)

....which, I suppose, justifies that comment...<g>

[Mike Mitchell]

On Thu, 8 Feb 2001 10:58:11 -0800, "Sjoerd Verweij"
<nospam.sjoerd@sjoerd.org> wrote:

>I never use Until. I could rant on about interprative distinction and
>consistency, but mostly it's taste.

I only use Until. No, really. I have been writing Do Until ...EOF for
as long as I can remember - years.

MM

[Bill McCarthy]

"Mark Burns" <mark@iolofpa.com> wrote in message
news:3a831d43@news.devx.com...
>
> Well...actually, to be completely fair, Jonathan *has* indeed shown an
> inkling or two of understanding, he's just proving recalcitrant/reticent
in
> acknowedging the importance/severity/impact of the problems in the Real
> World (where that #2 group is important and the opinion of the #1 group
does
> not rule the day more often than it does).
>

Yeh, actually that is true. Despite all his noise saying that Integer being
remapped was okay by him, there was that one post by him where he did admit
the truth !!

[Mark Burns]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3a83053a.1201853@news.devx.com...
> On Thu, 8 Feb 2001 10:58:11 -0800, "Sjoerd Verweij"
> <nospam.sjoerd@sjoerd.org> wrote:
>
> >I never use Until. I could rant on about interprative distinction and
> >consistency, but mostly it's taste.
>
> I only use Until. No, really. I have been writing Do Until ...EOF for
> as long as I can remember - years.

HERETIC! HERETIC!!! STONE...er...GOSUB HIM!! GOSUB HIM!!!<g>

[Jonathan Allen]

> Yeh, actually that is true. Despite all his noise saying that Integer
being
> remapped was okay by him, there was that one post by him where he did
admit
> the truth !!

Integer being remapped is still ok by me. It's the idea of dropping the
syntax entirely for the native IntXX format that you've convinced me of.

--
Jonathan Allen




"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:3a835282@news.devx.com...
>
> "Mark Burns" <mark@iolofpa.com> wrote in message
> news:3a831d43@news.devx.com...
> >
> > Well...actually, to be completely fair, Jonathan *has* indeed shown an
> > inkling or two of understanding, he's just proving recalcitrant/reticent
> in
> > acknowedging the importance/severity/impact of the problems in the Real
> > World (where that #2 group is important and the opinion of the #1 group
> does
> > not rule the day more often than it does).
> >
>
> Yeh, actually that is true. Despite all his noise saying that Integer
being
> remapped was okay by him, there was that one post by him where he did
admit
> the truth !!
>
>
>
>

[Mark Burns]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a839155@news.devx.com...
> > Yeh, actually that is true. Despite all his noise saying that Integer
> being
> > remapped was okay by him, there was that one post by him where he did
> admit
> > the truth !!
>
> Integer being remapped is still ok by me. It's the idea of dropping the
> syntax entirely for the native IntXX format that you've convinced me of.

Well then... I suppose you've only seen the half-light, then!<g>