And Then and Or Else

[Mark Hurd]

I still can't see a good excuse for Microsoft to not include a form of short-circuited
conditional operators.

Much of the discussion on the web has centered on why you can't turn the
existing conditional operators (which are really bit manipulation operators,
like & and | in C ) into short-circuited conditional operators (like && and
|| in C ). This is obvious to me. I assumed it would need a new syntax.

My suggestion is to use "And Then" and "Or Else", which is from some form
of BASIC in my past, but I don't remember which.

Can anyone give a valid reasoned argument why VB should not include this
sort of construct, other than "VB is not C"?

Mark Hurd
Director of Software Engineering
Netline Technologies International Ltd

[Darin Darin]

"Mark Hurd" <markhurd@ozemail.com.au> wrote:
>
>I still can't see a good excuse for Microsoft to not include a form of short-circuited
>conditional operators.

I remember being in a beta years ago for VB and asking the same question.
the MS program manager wrote me back saying that they thought it would be
too confusing to perform short circuiting because some of the elements of
the expression wouldn't be executed.


For example

If MyFunc(x) or MyFunc(y) Then


Where MyFunc() did something based on the input. If the MyFunc(x) returned
TRUE and they short circuited, then MyFunc(y) wouldn't be called.

Personally, I always thought that was a cop out.

[Matthew Solnit]

I think almost everyone can agree that syntactically understandable
short-circuiting would be a welcome addition to Visual Basic. Maybe MS just
doesn't realize how much demand there is, because we've been so busy asking
for the Big Three (inheritance, threading, constructors). Now that we've
got those in the bag, and since there's at least another year until VB7,
it's time to focus on medium-sized things like this.

mailto:vbwish@microsoft.com

"Mark Hurd" <markhurd@ozemail.com.au> wrote in message
news:38cc443a$1@news.devx.com...
>
> I still can't see a good excuse for Microsoft to not include a form of
short-circuited
> conditional operators.
>
> Much of the discussion on the web has centered on why you can't turn the
> existing conditional operators (which are really bit manipulation
operators,
> like & and | in C ) into short-circuited conditional operators (like &&
and
> || in C ). This is obvious to me. I assumed it would need a new syntax.
>
> My suggestion is to use "And Then" and "Or Else", which is from some form
> of BASIC in my past, but I don't remember which.
>
> Can anyone give a valid reasoned argument why VB should not include this
> sort of construct, other than "VB is not C"?

[Michael \(michka\) Kaplan]

"Matthew Solnit" <msolnit@yahoo.com> wrote in message
news:38ccf7da@news.devx.com...
> I think almost everyone can agree that syntactically understandable
> short-circuiting would be a welcome addition to Visual Basic. Maybe MS
just
> doesn't realize how much demand there is, because we've been so busy
asking
> for the Big Three (inheritance, threading, constructors). Now that we've
> got those in the bag, and since there's at least another year until VB7,
> it's time to focus on medium-sized things like this.
>

It is somewhat naive to believe that these features are in the bag and
done.... the statement made by the product managers and marketing folks is
that they are just about code complete but not quite.... this means that
TEST has really not ramped up yet, just that the bulk of the new code has
been written. Now, people complain all the time about how many buga re in
Microsoft products. Imagine Microsoft products minus a years worth of TEST
TEAM pounding and betas.

--
?MichKa
(insensitive fruitarian)

random junk of dubious value, a multilingual website, the
54-language TSI Form/Report to Data Access Page Wizard,
and lots of replication "stuff" at the (no scripts required!)
http://www.trigeminal.com/

[Craig Clearman]

Mark

>Can anyone give a valid reasoned argument why VB should not include this
>sort of construct, other than "VB is not C"?

I'd suggest that the easiest way to short-circuit is to do it in your
code:

If X Then
If Y Then
...
End If
End If

Is a lot more readable, to me, than

If X And Then Y Then
...
End If

Especially when X and Y become long enough to have overflow one line.

Otherwise, I don't care whether they add new capabilities.

Ciao, Craig

[Colin McGuigan]

Craig Clearman wrote in message ...
>I'd suggest that the easiest way to short-circuit is to do it in your
>code:
>
>If X Then
> If Y Then
> ...
> End If
>End If

The problem with this is when you want to have it be an either/or case,
instead of a this/that/the other thing case. Maybe that's a bad way to
phrase it, so let's take an example. Suppose I have a sub that takes in an
object, and needs to check to see if an object's Name property is not empty.
It's possible that the object passed will be Nothing, and so that needs to
be checked, too:

If obj Is Nothing Then
'Perform invalid object code here
ElseIf obj.Name = "" Then
'Perform invalid object code here
Else
'Perform valid object code here
End If

The problem is that you're repeating the same code twice; if the code's more
than two lines, this can start to make things more unreadable than they
should be, as well as hurting maintainability down the road. You can put
the object test into a function, or you can move the appropriate code into a
subroutine, but this breaks up what may otherwise be a simple procedure all
it's own.

>Is a lot more readable, to me, than
>
>If X And Then Y Then
> ...
>End If

I have to agree with you here; that syntax strikes me as incredibly forced.
I'd vote for AAnd and OOr myself (or maybe LAnd and LOr?).

For logical ands, you could always use 'If X Then If Y Then....' It seems a
little better...but it wouldn't handle parentheses well, and I can't think
of a suitable one for Or (or, worse, Xor)

>Especially when X and Y become long enough to have overflow one line.
>
>Otherwise, I don't care whether they add new capabilities.
>
>Ciao, Craig


--
Colin McGuigan

[Craig Clearman]

Hi Colin,

>The problem with this is when you want to have it be an either/or case,
>instead of a this/that/the other thing case. Maybe that's a bad way to
>phrase it, so let's take an example.

I know what you mean, and I'll generally choose two routes. Either
I'll put all of the repeated code into a subroutine (as you mentioned
later down the line), or I'll force a boolean value to true. Then, I
can evaluate the boolean after my If's and run the positive and
negative routines based upon the boolean.

Not ideal, I agree.

Your example would look like this:

If obj Is Nothing Then
bObjectIsValid = False
ElseIf obj.Name = "" Then
bObjectIsValid = False
Else
bObjectIsValid = True
End If

If bObjectIsValid Then
'Perform valid object code here
Else
'Perform invalid object code here
End If

And you're right. The biggest problem is that I've gone from 5 lines
to 12. However, I think you'll find that when you want to add more
requirements to having a valid object, this way is easier to maintain.

>>Especially when X and Y become long enough to have overflow one line.

To have? To have? Proofread next time, Craig. (ed: Sure, that'll
happen.)

Ciao, Craig

[Alan Gillott]

But that isn't the point: why make your structure deeper and less readable
just to overcome a compiler quirk? Especially when both failures need the
same "else" clause. That means you have to repeat code or add a procedure
you wouldn't bother with otherwise or wimp out and create a GoSub.
If A then
If b then
do c
else
do d
end if
else
do d
end if
If there are several of these you sure get bored repeating d. Short
circuiting would sure reduce some of my structures. Reminds me of my
PL/1|PL/s days where an Else clause could be 20 or 30 pages from the If
then. Painful when reading code from microfiche.

Craig Clearman <chclear@nospam.please> wrote in message
news:p5hqcs08ab51jtvmu5b7vb13bgq74j3s0h@4ax.com...
> Mark
>
> >Can anyone give a valid reasoned argument why VB should not include this
> >sort of construct, other than "VB is not C"?
>
> I'd suggest that the easiest way to short-circuit is to do it in your
> code:
>
> If X Then
> If Y Then
> ...
> End If
> End If
>
> Is a lot more readable, to me, than
>
> If X And Then Y Then
> ...
> End If
>
> Especially when X and Y become long enough to have overflow one line.
>
> Otherwise, I don't care whether they add new capabilities.
>
> Ciao, Craig
>

[Craig Clearman]

Alan,

>If there are several of these you sure get bored repeating d.

See my note to Colin for the structure I use in this case.

I tend to see more problems when people attempt short-circuiting:

If W && X && Y && Z Then
...
Else
...
End If

They keep adding more and more onto that line when maintaining the
code. Eventually, you have an if statement that is five or six lines
long (if they even bothered using a line continuation character).

I'd just like to reiterate my original post:

>> Otherwise, I don't care whether they add new capabilities.

Ciao, Craig

[Michael \(michka\) Kaplan]

I would avoid creating a gosub, due to the poor way that the compiler
optimizes it.

--
?MichKa
(insensitive fruitarian)

random junk of dubious value, a multilingual website, the
54-language TSI Form/Report to Data Access Page Wizard,
and lots of replication "stuff" at the (no scripts required!)
http://www.trigeminal.com/

?
"Alan Gillott" <agillott@tact.com> wrote in message
news:38cd50e5$1@news.devx.com...
> But that isn't the point: why make your structure deeper and less readable
> just to overcome a compiler quirk? Especially when both failures need the
> same "else" clause. That means you have to repeat code or add a procedure
> you wouldn't bother with otherwise or wimp out and create a GoSub.
> If A then
> If b then
> do c
> else
> do d
> end if
> else
> do d
> end if
> If there are several of these you sure get bored repeating d. Short
> circuiting would sure reduce some of my structures. Reminds me of my
> PL/1|PL/s days where an Else clause could be 20 or 30 pages from the If
> then. Painful when reading code from microfiche.
>
> Craig Clearman <chclear@nospam.please> wrote in message
> news:p5hqcs08ab51jtvmu5b7vb13bgq74j3s0h@4ax.com...
> > Mark
> >
> > >Can anyone give a valid reasoned argument why VB should not include
this
> > >sort of construct, other than "VB is not C"?
> >
> > I'd suggest that the easiest way to short-circuit is to do it in your
> > code:
> >
> > If X Then
> > If Y Then
> > ...
> > End If
> > End If
> >
> > Is a lot more readable, to me, than
> >
> > If X And Then Y Then
> > ...
> > End If
> >
> > Especially when X and Y become long enough to have overflow one line.
> >
> > Otherwise, I don't care whether they add new capabilities.
> >
> > Ciao, Craig
> >
>
>

[Alan Gillott]

Michael
I forgot the sign for "Tongue Firmly In Cheek" <grin>
Alan
Michael (michka) Kaplan <former_mvp@spamless.trigeminal.spamless.com> wrote
in message news:38cd8f6a@news.devx.com...
> I would avoid creating a gosub, due to the poor way that the compiler
> optimizes it.
>
> --
> ?MichKa
> (insensitive fruitarian)
>
> random junk of dubious value, a multilingual website, the
> 54-language TSI Form/Report to Data Access Page Wizard,
> and lots of replication "stuff" at the (no scripts required!)
> http://www.trigeminal.com/
>
> ?
> "Alan Gillott" <agillott@tact.com> wrote in message
> news:38cd50e5$1@news.devx.com...
> > But that isn't the point: why make your structure deeper and less
readable
> > just to overcome a compiler quirk? Especially when both failures need
the
> > same "else" clause. That means you have to repeat code or add a
procedure
> > you wouldn't bother with otherwise or wimp out and create a GoSub.
> > If A then
> > If b then
> > do c
> > else
> > do d
> > end if
> > else
> > do d
> > end if
> > If there are several of these you sure get bored repeating d. Short
> > circuiting would sure reduce some of my structures. Reminds me of my
> > PL/1|PL/s days where an Else clause could be 20 or 30 pages from the If
> > then. Painful when reading code from microfiche.
> >
> > Craig Clearman <chclear@nospam.please> wrote in message
> > news:p5hqcs08ab51jtvmu5b7vb13bgq74j3s0h@4ax.com...
> > > Mark
> > >
> > > >Can anyone give a valid reasoned argument why VB should not include
> this
> > > >sort of construct, other than "VB is not C"?
> > >
> > > I'd suggest that the easiest way to short-circuit is to do it in your
> > > code:
> > >
> > > If X Then
> > > If Y Then
> > > ...
> > > End If
> > > End If
> > >
> > > Is a lot more readable, to me, than
> > >
> > > If X And Then Y Then
> > > ...
> > > End If
> > >
> > > Especially when X and Y become long enough to have overflow one line.
> > >
> > > Otherwise, I don't care whether they add new capabilities.
> > >
> > > Ciao, Craig
> > >
> >
> >
>
>

[Al Meadows]

>>The problem is that you're repeating the same code twice;

Seems to me that that was why GoSub was created.


"Colin McGuigan" <colin@chicor.com> wrote in message
news:38cd4bc0$1@news.devx.com...
> Craig Clearman wrote in message ...
> >I'd suggest that the easiest way to short-circuit is to do it in your
> >code:
> >
> >If X Then
> > If Y Then
> > ...
> > End If
> >End If
>
> The problem with this is when you want to have it be an either/or case,
> instead of a this/that/the other thing case. Maybe that's a bad way to
> phrase it, so let's take an example. Suppose I have a sub that takes in
an
> object, and needs to check to see if an object's Name property is not
empty.
> It's possible that the object passed will be Nothing, and so that needs to
> be checked, too:
>
> If obj Is Nothing Then
> 'Perform invalid object code here
> ElseIf obj.Name = "" Then
> 'Perform invalid object code here
> Else
> 'Perform valid object code here
> End If
>
> The problem is that you're repeating the same code twice; if the code's
more
> than two lines, this can start to make things more unreadable than they
> should be, as well as hurting maintainability down the road. You can put
> the object test into a function, or you can move the appropriate code into
a
> subroutine, but this breaks up what may otherwise be a simple procedure
all
> it's own.
>
> >Is a lot more readable, to me, than
> >
> >If X And Then Y Then
> > ...
> >End If
>
> I have to agree with you here; that syntax strikes me as incredibly
forced.
> I'd vote for AAnd and OOr myself (or maybe LAnd and LOr?).
>
> For logical ands, you could always use 'If X Then If Y Then....' It seems
a
> little better...but it wouldn't handle parentheses well, and I can't think
> of a suitable one for Or (or, worse, Xor)
>
> >Especially when X and Y become long enough to have overflow one line.
> >
> >Otherwise, I don't care whether they add new capabilities.
> >
> >Ciao, Craig
>
>
> --
> Colin McGuigan
>
>
>

[Matthew Solnit]

You are correct. What I meant by "in the bag" is that we are definitely
going to have them in VB7. We don't have to ask anymore. At least, I
cannot conceive of MS changing their minds all of a sudden, but it would
almost be fun to watch the public reaction <evil grin>

What's an insensitive fruitarian? The latter term was discussed in "Notting
Hill" but I wasn't sure if they (or you) meant it seriously.

"Michael (michka) Kaplan" <former_mvp@spamless.trigeminal.spamless.com>
wrote in message news:38cd3ff4$1@news.devx.com...
> It is somewhat naive to believe that these features are in the bag and
> done.... the statement made by the product managers and marketing folks is
> that they are just about code complete but not quite.... this means that
> TEST has really not ramped up yet, just that the bulk of the new code has
> been written. Now, people complain all the time about how many buga re in
> Microsoft products. Imagine Microsoft products minus a years worth of TEST
> TEAM pounding and betas.
>
> --
> ?MichKa
> (insensitive fruitarian)
>
> random junk of dubious value, a multilingual website, the
> 54-language TSI Form/Report to Data Access Page Wizard,
> and lots of replication "stuff" at the (no scripts required!)
> http://www.trigeminal.com/
>
>
> "Matthew Solnit" <msolnit@yahoo.com> wrote in message
> news:38ccf7da@news.devx.com...
> > I think almost everyone can agree that syntactically understandable
> > short-circuiting would be a welcome addition to Visual Basic. Maybe MS
> just
> > doesn't realize how much demand there is, because we've been so busy
> asking
> > for the Big Three (inheritance, threading, constructors). Now that
we've
> > got those in the bag, and since there's at least another year until VB7,
> > it's time to focus on medium-sized things like this.

[Colin McGuigan]

Al Meadows wrote in message <38ce4342$1@news.devx.com>...
>>>The problem is that you're repeating the same code twice;
>
>Seems to me that that was why GoSub was created.


No...that's why subroutines were created. GoSubs are ugly, and less and
less programmers know how to use them elegantly (if you can call it that).

That, and with MS' optimizations to VB, since VB4 (I believe), using a GoSub
has been slower than using a new subroutine anyway. So you don't even save
anything.


--
Colin McGuigan

[Michael \(michka\) Kaplan]

Notting Hill is what the reference is alluding to. I believe that fruits and
vegetables had feelings, and that cooking is cruel. The insensitive part
comes from the fact that I don't care!

("Die, carrots!")

--
?MichKa
(insensitive fruitarian)

random junk of dubious value, a multilingual website, the
54-language TSI Form/Report to Data Access Page Wizard,
and lots of replication "stuff" at the (no scripts required!)
http://www.trigeminal.com/

?
"Matthew Solnit" <msolnit@yahoo.com> wrote in message
news:38ce495c@news.devx.com...
> You are correct. What I meant by "in the bag" is that we are definitely
> going to have them in VB7. We don't have to ask anymore. At least, I
> cannot conceive of MS changing their minds all of a sudden, but it would
> almost be fun to watch the public reaction <evil grin>
>
> What's an insensitive fruitarian? The latter term was discussed in
"Notting
> Hill" but I wasn't sure if they (or you) meant it seriously.
>
> "Michael (michka) Kaplan" <former_mvp@spamless.trigeminal.spamless.com>
> wrote in message news:38cd3ff4$1@news.devx.com...
> > It is somewhat naive to believe that these features are in the bag and
> > done.... the statement made by the product managers and marketing folks
is
> > that they are just about code complete but not quite.... this means that
> > TEST has really not ramped up yet, just that the bulk of the new code
has
> > been written. Now, people complain all the time about how many buga re
in
> > Microsoft products. Imagine Microsoft products minus a years worth of
TEST
> > TEAM pounding and betas.
> >
> > --
> > ?MichKa
> > (insensitive fruitarian)
> >
> > random junk of dubious value, a multilingual website, the
> > 54-language TSI Form/Report to Data Access Page Wizard,
> > and lots of replication "stuff" at the (no scripts required!)
> > http://www.trigeminal.com/
> >
> >
> > "Matthew Solnit" <msolnit@yahoo.com> wrote in message
> > news:38ccf7da@news.devx.com...
> > > I think almost everyone can agree that syntactically understandable
> > > short-circuiting would be a welcome addition to Visual Basic. Maybe
MS
> > just
> > > doesn't realize how much demand there is, because we've been so busy
> > asking
> > > for the Big Three (inheritance, threading, constructors). Now that
> we've
> > > got those in the bag, and since there's at least another year until
VB7,
> > > it's time to focus on medium-sized things like this.
>
>

[Karl E. Peterson]

Hi Colin --

>>>>The problem is that you're repeating the same code twice;
>>
>>Seems to me that that was why GoSub was created.
>
>No...that's why subroutines were created. GoSubs are ugly, and less and
>less programmers know how to use them elegantly (if you can call it that).

They _were_ very useful for isolating multiple-use code within a procedure, though.
The main advantage being no need to stuff the stack with a boatload of in-scope
variables. IOW, they were most definitely an optimization over separate subroutines
in cases where the code in question was only used from a single location.

>That, and with MS' optimizations to VB, since VB4 (I believe), using a GoSub
>has been slower than using a new subroutine anyway. So you don't even save
>anything.

You're telling the guy who reported that to MS during the VB4 beta. ;-)

Later... Karl

[Colin McGuigan]

Karl E. Peterson wrote in message <38ce881e@news.devx.com>...
>Hi Colin --
>They[GoSubs] _were_ very useful for isolating multiple-use code within a
procedure, though.
>The main advantage being no need to stuff the stack with a boatload of
in-scope
>variables. IOW, they were most definitely an optimization over separate
subroutines
>in cases where the code in question was only used from a single location.

Yeah, I'd admit that there are places where you might have some code where a
GoSub would fit in just right, and make everything nice and clean. I
believe that those are few and far between compared to the ones where you're
better off using a subroutine, or restructuring your code, though. I don't
think that they're an adequate alternative to logical operands, though,
which was the original point (if you don't have logical operands, you may
end up in places where you're executing the same code twice, etc...)

>>That, and with MS' optimizations to VB, since VB4 (I believe), using a
GoSub
>>has been slower than using a new subroutine anyway. So you don't even
save
>>anything.


>You're telling the guy who reported that to MS during the VB4 beta. ;-)

Well, then, one would've expected you to remember! <ducks, then sidesteps>
I harbor the cynical belief that they did it on purpose to discourage
continued use of GoSubs, but that's just me being paranoid.

>Later... Karl


--
Colin McGuigan

[Karl E. Peterson]

Hi Colin --

>Yeah, I'd admit that there are places where you might have some code where a
>GoSub would fit in just right, and make everything nice and clean. I
>believe that those are few and far between compared to the ones where you're
>better off using a subroutine, or restructuring your code, though.

I tend to agree, which is why I never got as excited about this sub-optimization in
VB4.

>>You're telling the guy who reported that to MS during the VB4 beta. ;-)
>
>Well, then, one would've expected you to remember! <ducks, then sidesteps>

Heheheh... I was just a sympathizer, on that round. <g>

"Compiler Al" was principal complainant.

>I harbor the cynical belief that they did it on purpose to discourage
>continued use of GoSubs, but that's just me being paranoid.

Just 'cause you're paranoid doesn't mean they're not out to get you!

(IOW, I think you're right, and the evidence supports this view.)

Later... Karl

[Matthew Cromer]

in article 38ce5a1c$1@news.devx.com, Colin McGuigan at colin@chicor.com
wrote on 3/14/00 10:40 AM:

> Al Meadows wrote in message <38ce4342$1@news.devx.com>...
>>>> The problem is that you're repeating the same code twice;
>>
>> Seems to me that that was why GoSub was created.
>
>
> No...that's why subroutines were created. GoSubs are ugly, and less and
> less programmers know how to use them elegantly (if you can call it that).
>
> That, and with MS' optimizations to VB, since VB4 (I believe), using a GoSub
> has been slower than using a new subroutine anyway. So you don't even save
> anything.
>
>
> --
> Colin McGuigan
>
>
>


The advantage of a gosub is you don't have to pass in your variables.

The place I use gosub (very occasionally) is in error-checking code where I
don't want to have to cache the error code into a parameter (because calling
a function resets the error context inside the function).

--
Matthew Cromer
President, SDA Consulting, Inc.
matthew@sdaconsulting.com
http://www.sdaconsulting.com/
(919) 274-0074

[Matthew Solnit]

LOL

"Michael (michka) Kaplan" <former_mvp@spamless.trigeminal.spamless.com>
wrote in message news:38ce7957$1@news.devx.com...
>
> ("Die, carrots!")

[Mark Hurd]

OK, I've been away from this NG from straight after sending the message
initiating this thread. Here is the summary of what I intend responding to:

Some say, No: Short-Circuiting causes bad, non-maintainable code.

Some say, Yes, but use different syntax to my suggestion. (But then shoot
themselves in the foot by implying AAnd and OOr are LESS FORCED than And
Then and Or Else!)

Some say, Yes: Microsoft need to consider "lesser" features now.

My response:

Firstly, I don't mind what syntax, again assuming it won't break existing
code; I just want short circuiting. (Yes, this is just the first item on my
adgenda of adding all of the C constructs to VB! ++ and -- next, again
because they really do allow for HAND optimising of code.)

The complaint about maintenance and long codelines is a VB problem already.
There are more C features that would help here too, like consecutive string
literals being automatically concatenated at compile-time. That would allow
long strings to be broken into readble chunks in the source and not using
run-time resources to join them up again.

My best option for short-circuiting now is to use the Select statement:

Select Case True
Case Condition1
' Executes when C1 is True (C2 not evaluated)
Case Condition2
' Executes when Not C1 And C2 is True
Case Else
' Executes when Not C1 And Not C2 is True; Not (C1 Or C2) is True
End Select

I first noticed this when an existing Select Case True statement (often used
to make an ElseIf statement to be more readable) evolved into one with code
only in the Case Else.

So your standard, reference validation becomes:

Select Case True
Case ref Is Nothing
Case ref.Value = 0
Case Else
Result = 1/ref.Value
End Select

(Obviously a bad example for so many reasons...)

My suggested syntax:

If Not (ref Is Nothing) And Then ref.Value <> 0 Then
Etc...

Or even:

If Not (ref Is Nothing Or Else ref.Value = 0) Then
Etc...


The Microsoft suggestion about not knowing if Y() is executed in X() Or Else
Y() is *exactly* why we want the feature!

I suppose I should concede that many people are not able to comprehend
boolean expressions as well as me (I ALWAYS remove = True and convert =
False into Not ...) but I don't see any reason why a language that has all
the boolean operators as VB shouldn't havd some way to get short-circuiting.

Quite clearly we have worked around and avoided it for years, but I still
think it is worth pushing for it,
Mark Hurd, B.Sc.(Ma.)(Hons.)
Director of Software Engineering
Netline Technologies International Ltd

[Alan Gillott]

Maybe I am the classic Equivocator. I want short circuiting so that I can do
somthing like:
if IsMissing(x) and not x then ...
But I shy away from If Proc(x) and Proc(y) believing that it is bad
programming practice to build complex hard to debug statements because ease
of debugging is more important than overly clever statements. I see this
usage a lot in C but the poor design of the C language forces these
constructs where all the function is buried inside some arcane header file.
But for VB where most procedure calls are business logic, then it should be
axiomatic that, if x and y have outputs other than the returned value thay
should NOT be buried inside an IF statement. I want to see them clearly in
the main path of the routine.

I do not believe that short circuiting requires any special syntactical
change, and that code that would be affected by short circuiting is
intrinsically bad code.

That said, changing VB now to introduce short circuiting will affect many
programs and consequently it might be preferable to introduce a new form of
IF rather than wierd syntax to overcome the deficiencies of the existing IF.


Mark Hurd <markhurd@ozemail.com.au> wrote in message
news:38d70dc0@news.devx.com...
> OK, I've been away from this NG from straight after sending the message
> initiating this thread. Here is the summary of what I intend responding
to:
>
> Some say, No: Short-Circuiting causes bad, non-maintainable code.
>
> Some say, Yes, but use different syntax to my suggestion. (But then shoot
> themselves in the foot by implying AAnd and OOr are LESS FORCED than And
> Then and Or Else!)
>
> Some say, Yes: Microsoft need to consider "lesser" features now.
>
> My response:
>
> Firstly, I don't mind what syntax, again assuming it won't break existing
> code; I just want short circuiting. (Yes, this is just the first item on
my
> adgenda of adding all of the C constructs to VB! ++ and -- next, again
> because they really do allow for HAND optimising of code.)
>
> The complaint about maintenance and long codelines is a VB problem
already.
> There are more C features that would help here too, like consecutive
string
> literals being automatically concatenated at compile-time. That would
allow
> long strings to be broken into readble chunks in the source and not using
> run-time resources to join them up again.
>
> My best option for short-circuiting now is to use the Select statement:
>
> Select Case True
> Case Condition1
> ' Executes when C1 is True (C2 not evaluated)
> Case Condition2
> ' Executes when Not C1 And C2 is True
> Case Else
> ' Executes when Not C1 And Not C2 is True; Not (C1 Or C2) is True
> End Select
>
> I first noticed this when an existing Select Case True statement (often
used
> to make an ElseIf statement to be more readable) evolved into one with
code
> only in the Case Else.
>
> So your standard, reference validation becomes:
>
> Select Case True
> Case ref Is Nothing
> Case ref.Value = 0
> Case Else
> Result = 1/ref.Value
> End Select
>
> (Obviously a bad example for so many reasons...)
>
> My suggested syntax:
>
> If Not (ref Is Nothing) And Then ref.Value <> 0 Then
> Etc...
>
> Or even:
>
> If Not (ref Is Nothing Or Else ref.Value = 0) Then
> Etc...
>
>
> The Microsoft suggestion about not knowing if Y() is executed in X() Or
Else
> Y() is *exactly* why we want the feature!
>
> I suppose I should concede that many people are not able to comprehend
> boolean expressions as well as me (I ALWAYS remove = True and convert =
> False into Not ...) but I don't see any reason why a language that has all
> the boolean operators as VB shouldn't havd some way to get
short-circuiting.
>
> Quite clearly we have worked around and avoided it for years, but I still
> think it is worth pushing for it,
> Mark Hurd, B.Sc.(Ma.)(Hons.)
> Director of Software Engineering
> Netline Technologies International Ltd
>
>

[Eduardo A. Morcillo]

Maybe the best solution is to add an Option ShortCircuiting statement. That
will not break code and will mantain the If-Then-Else syntax.

--
Eduardo A. Morcillo
http://www.domaindlx.com/e_morcillo

[Mark Hurd]

Thanks, that's the first time I've seen a reason why people might assume the
same syntax.

However, I don't agree with you about side-effects in conditionals being bad
code for VB (as I have said in other places, I use VB like C, but keep both
more structured than the languages force you to be).

I do agree that side-effects in general have to be well documented and
'sensible', but C-like If statements like this:

If StartThing And Thing.OK Then

are more readable to me than:

Dim bStarted As Boolean

bStarted = StartThing

If bStarted Then ' bStarted is never used again

If Thing.OK Then

and even more so when it is not an And but and Or being tested.

Like I said in a deeper part of this thread, I know I like boolean
expressions more than others, and I seemed to understand (comprehend)
short-circuited conditionals just as well.

Mark Hurd, B.Sc.(Ma.)(Hons.)
Director of Software Engineering
Netline Technologies International Ltd

[Alan Gillott]

An Aussie Eh!
I have a lot of good friends down there and a healthy respect for the
growing software industry. Keep up the good work.
Alan

Mark Hurd <markhurd@ozemail.com.au> wrote in message
news:38d9f6a2@news.devx.com...
> Thanks, that's the first time I've seen a reason why people might assume
the
> same syntax.
>
> However, I don't agree with you about side-effects in conditionals being
bad
> code for VB (as I have said in other places, I use VB like C, but keep
both
> more structured than the languages force you to be).
>
> I do agree that side-effects in general have to be well documented and
> 'sensible', but C-like If statements like this:
>
> If StartThing And Thing.OK Then
>
> are more readable to me than:
>
> Dim bStarted As Boolean
>
> bStarted = StartThing
>
> If bStarted Then ' bStarted is never used again
>
> If Thing.OK Then
>
> and even more so when it is not an And but and Or being tested.
>
> Like I said in a deeper part of this thread, I know I like boolean
> expressions more than others, and I seemed to understand (comprehend)
> short-circuited conditionals just as well.
>
> Mark Hurd, B.Sc.(Ma.)(Hons.)
> Director of Software Engineering
> Netline Technologies International Ltd
>
>

[Evan A. Barr]

I thought I was the only one who wanted short circuited If statements and
so I've kept it to myself.

My only modification to your "If, And Then, Then" syntax would be - If, And
If, And If, Then.

If FuncA() And If FuncB() Then
Stuff
Else
OtherStuff
End If


I am also someone who replaces
If X = False Then
with
If Not X Then
This is more English like and more readable (to me and many).


As to statements about Gosub, FORTRAN allows for functions to contain other
functions. At first this sounds like something that would make a function
more complicated, but it generally simplifies already complex functions and
would replace all Gosubs.

For a few lines of repeated code that is useless outside of the current function,
you define a "contained function" that compiles IN-LINE. If the contained
function has parameters, the result is variable replacement AT COMPILE TIME
(allowed since the function is in-line). I have long missed this feature.

Contained functions also provide a means to control variable lifetime without
resorting to a subroutine. I hate creating variables that will only be used
for a few lines of a large function. But I also hate reusing variables when
the variable name no longer represents what it contains.


Hope no one minds how far off the subject I have gone.
-
Evan A. Barr MCSD
Director of Development
SME Corporation

[Ron Paredes]

"Darin" Darin wrote:
>
>I remember being in a beta years ago for VB and asking the same question.
>the MS program manager wrote me back saying that they thought it would be
>too confusing to perform short circuiting because some of the elements of
>the expression wouldn't be executed.
>
>
>For example
>
> If MyFunc(x) or MyFunc(y) Then
>
>
>Where MyFunc() did something based on the input. If the MyFunc(x) returned
>TRUE and they short circuited, then MyFunc(y) wouldn't be called.
>
>Personally, I always thought that was a cop out.
>
>

I think every VB programmer who comes from C or Pascal would
agree that short-circuiting is more efficient, now why would a good programmer
expect MyFunc(y) be evaluated if MyFunc(x) already returns true? unless MyFunc(y)
opens a file and the THEN part assumes that the file is already open and
use it, BOOM. I think VB is too lenient even for the greatest stupid practices
in programming history. If I wanna shoot myself in the foot, I'd use VC++
or Java, but then I have to aim good, If I wanna shoot both feet with a single
bullet, i'd use VB, without even aiming.
Hehehe, don't get me wrong guys, I do love VB.


Ron Paredes

[Travis Hall]

Craig Clearman <chclear@nospam.please> wrote:
>
>They keep adding more and more onto that line when maintaining the
>code. Eventually, you have an if statement that is five or six lines
>long (if they even bothered using a line continuation character).

You can't really criticise a feature on the basis that some so-called programmers
will use it badly. Once you start doing that, you really have to bag VB as
a whole.

(The most horrid code I have encountered in real use is all VB code. Why?
Because VB makes programming easy enough that even an almost complete incompetent
can get a simple program to run. This doesn't make VB bad, because that ease
of use also helps the good programmers - it's a definite plus.)

Used correctly, these "short-circuited" conditionals would be of benefit
to decent programmers - just as much as the basic And and Or conditionals
we already have, when you think about it.

Travis Hall

[Craig Clearman]

Travis,

>You can't really criticise a feature on the basis that some so-called programmers
>will use it badly.

Sure I can.

>(The most horrid code I have encountered in real use is all VB code. Why?

The worst I've seen was Perl.

Ciao, Craig

[Michael \(michka\) Kaplan]

I see this sort of thing misused in C and C++ code often.

--
?MichKa
(insensitive fruitarian)

random junk of dubious value, a multilingual website, the
54-language TSI Form/Report to Data Access Page Wizard,
and lots of replication "stuff" at the (no scripts required!)
http://www.trigeminal.com/

?
"Travis Hall" <hallt@qst.newsltd.com.au> wrote in message
news:38de93a6$1@news.devx.com...
>
> Craig Clearman <chclear@nospam.please> wrote:
> >
> >They keep adding more and more onto that line when maintaining the
> >code. Eventually, you have an if statement that is five or six lines
> >long (if they even bothered using a line continuation character).
>
> You can't really criticise a feature on the basis that some so-called
programmers
> will use it badly. Once you start doing that, you really have to bag VB as
> a whole.
>
> (The most horrid code I have encountered in real use is all VB code. Why?
> Because VB makes programming easy enough that even an almost complete
incompetent
> can get a simple program to run. This doesn't make VB bad, because that
ease
> of use also helps the good programmers - it's a definite plus.)
>
> Used correctly, these "short-circuited" conditionals would be of benefit
> to decent programmers - just as much as the basic And and Or conditionals
> we already have, when you think about it.
>
> Travis Hall

[Travis Hall]

"Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote:
>I see this sort of thing misused in C and C++ code often.

So?

Global variables are misued horribly all the time, but I think we all acknowledge
that they have their uses. Goto encourages the worst of programming practices,
but without it we wouldn't have VB error handling at all (although, with
SEH in VB7, that may change somewhat). Any looping structure can be used
to create an infinite loop and lock up a program, but none of us would even
consider using a high-level language that does not offer them. The ability
to nest conditionals and looping structures can result in arcane, unmaintainable
code with bugs that are almost impossible to hunt down, yet we use nested
conditionals (correctly) all the time.

All programming languages are full of features that can be misused, but those
features are there because they are useful. If you expect the language to
make someone a good programmer, you are just going to end up with a lot of
really crappy code. All the language can do is provide the tools. It's up
to the programmer to use them, not abuse them.

Travis Hall

[Travis Hall]

Craig Clearman <chclear@nospam.please> wrote:
>Travis,
>
>>You can't really criticise a feature on the basis that some so-called programmers
>>will use it badly.
>
>Sure I can.

Not usefully you can't.

>>(The most horrid code I have encountered in real use is all VB code. Why?
>
>The worst I've seen was Perl.

Good for you. My point remains - the very same ease of use of VB that results
in such good productivity for us all can be used badly. Just like short-circuited
conditionals can be used to good effect, or used badly.

Travis Hall

[Craig Clearman]

X-Newsreader: Forte Agent 1.7/32.534
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 168.75.116.3
X-Trace: 27 Mar 2000 18:59:05 -0800, 168.75.116.3
Lines: 21
Path: news.devx.com!168.75.116.3
Xref: news.devx.com vb.vb7:392

Travis,

>>>You can't really criticise a feature on the basis that some so-called programmers
>>>will use it badly.
>>
>>Sure I can.
>
>Not usefully you can't.

Good thing I'm not limited to doing something useful.

>>>(The most horrid code I have encountered in real use is all VB code. Why?
>>
>>The worst I've seen was Perl.
>
>Good for you.

Thanks.

Ciao, Craig

[Mike Mitchell]

On Mon, 13 Mar 2000 14:26:54 -0600, "Colin McGuigan"
<colin@chicor.com> wrote:

>
>If obj Is Nothing Then
> 'Perform invalid object code here
>ElseIf obj.Name = "" Then
> 'Perform invalid object code here
>Else
> 'Perform valid object code here
>End If
>

Why not try something simple and effective:

MyName = "Error"
On Error Resume Next
MyName = obj.Name

MM

[John Perkins]

Mike,

Your example doesn't solve the problem.

Obj.Name will indeed be equal to "Error" in your example, but you will still
need to check if the object is valid before proceeding with any other work
with the object, and then perform cleanup if it is not. Or were just just
going to ignore every error that might occur with your On Error Resume Next?

-John Perkins

"Mike Mitchell" <fourumonster@hotmail.com> wrote in message
news:3971a846.7328979@news.devx.com...
> On Mon, 13 Mar 2000 14:26:54 -0600, "Colin McGuigan"
> <colin@chicor.com> wrote:
>
> >
> >If obj Is Nothing Then
> > 'Perform invalid object code here
> >ElseIf obj.Name = "" Then
> > 'Perform invalid object code here
> >Else
> > 'Perform valid object code here
> >End If
> >
>
> Why not try something simple and effective:
>
> MyName = "Error"
> On Error Resume Next
> MyName = obj.Name
>
> MM
>