VB6 vs VB.NET...Procedure Calling Syntax

[Patrick Troughton]

Here's another example where VB.NET is easier than VB6. If you're joining
us late, Tuesday we covered how creating a user control is much easier in
VB.NET.....

http://news.devx.com/cgi-bin/dnewswe...em=44342&utag=

Wednesday, we saw how using a file open dialog is easier in VB.NET....

http://news.devx.com/cgi-bin/dnewswe...em=44447&utag=

Today, we'll switch to a completely different subject...language syntax.
Specifically, let's look at how VB.NET syntax for calling a procedure is
easier than in VB6. This example applies to both beginner and intermediate
programmers. Advanced programmers probably code them without even thinking
about it. OK, let's look at VB6 first...

In VB6, there are five separate rules (plus 2 special cases) for when you
use parenthesis around an argument list and when you don't. Let's go through
each rule, one at a time. I'll also provide an example of each because this
can kind of get confusing.

Rule 1....Calling a Subroutine with the Call Keyword. When calling a subroutine
using the Call keyword, you must use parenthesis around the parameter list.
Example....

Call MySub(Parm1, Parm2)

Failure to do so will cause a compile error.

Rule 2....Calling a Subroutine Without the Call Keyword. When calling a subroutine
without using the Call keyword, you cannot use parenthesis around the parameter
list. Example....

MySub Parm1, Parm2

If you mistakenly use parenthesis around the parameter list, you will get
a compile error.

Rule 3....Calling a Function, Storing the Return Value in a Variable. When
calling a function and you store the return value into a variable, you must
use parenthesis around the parameter list. For example.....

MyReturnValue = MyFunction(Parm1, Parm2)

Failure to do so will cause a compile error.

Rule 4....Calling a Function, Ignoring the Return Value. When calling a
function and you don't use the return value, you cannot use parenthesis.
For example....

MyFunction Parm1, Parm2

If you mistakenly use parenthesis around the parameter list, you will get
a compile error.

Rule 5....Calling a Function, Ignoring the Return Value Using the Call Keyword.
When calling a function, ignoring the return value and using the Call keyword
you must use parenthesis. For example....

Call MyFunction(Parm1, Parm2)

Failure to do so will cause a compile error.

Rule 6....Calling a Subroutine Without the Call Keyword But with Only One
Parameter (Special Case of Rule 2). When calling a subroutine that accepts
only one parameter, and you don't use the Call keyword, you can use a parenthesis.
However, the behavior now changes such that the parameter is passed by value
even if the parameter is declared in the subroutine by reference. Example...

MySub (Parm1)

This line of code will compile regardless of whether there are parenthesis,
however the behavior may be different (see above).

Rule 7....Calling a Function Without the Call Keyword But with Only One Parameter
Ignoring the Return Value (Special Case of Rule 4). When calling a function
that accepts only one parameter, and you don't use the Call keyword, you
can use a parenthesis. However, the behavior now changes such that the parameter
is passed by value even if the parameter is declared in the function by reference.
Example:

MyFunction (Parm1)

This line of code will compile regardless of whether there are parenthesis,
however the behavior may be different (see above).

Now, let's take a lot at VB.NET.

Rule 1....Always Use Parenthesis.

Examples:

MySub (Parm1 Parm2)
Call MySub(Parm1, Parm2)
MyReturnValue = MyFunction(Parm1, Parm2)
MyFunction(Parm1, Parm2)
Call MyFunction(Parm1, Parm2)
MySub(Parm1)
MyFunction(Parm1)

Forgetting to use the parethesis in VB.NET will not cause a compile error
because the VB.NET's IntelliSense.

OK, you be the judge. Which procedure calling syntax do you think is easier
and why?

/Pat

[Frank Oquendo]

Patrick Troughton had this to say:

> Here's another example where VB.NET is easier than VB6. If you're
> joining us late, Tuesday we covered how creating a user control is
> much easier in VB.NET.....

That user control example was hilarious!

--
"If you want to be somebody else change your mind"
http://www.acadx.com
http://vbxtender.sourceforge.net

[Jens]

Keep this up Patrick, I'm pretty sure that most NOTters will not respond to
this interesting series, since it is too technical for them. They might
even finally understand things they have been doing all these years without
knowing why.

Jens

[Frank Oquendo]

DonB had this to say:

> My rules have always been
>
> Call MySub(p1, p2)
> x = MyFunc(p1, p2)

The point is that those are *your* rules, not the compiler's.

> On the other hand, when I first took a stab at writing a simple
> "ping" app, the complexity of wading through System.Net.Sockets to
> simply figure out how to specify the IP address raised my blood
> pressure at least 30 points.

It really wasn't all that hard to follow. I just read the help.

> When .NET confronts you with a "fork in the road", it seems like
> there are at least a dozen paths to choose. Not good.

There's two ways to look at this:

1) How is VB's handling of parameters any different?
2) Since when is flexibility a bad thing?

--
"If you want to be somebody else change your mind"
http://www.acadx.com
http://vbxtender.sourceforge.net

[DonB]

My rules have always been

Call MySub(p1, p2)
x = MyFunc(p1, p2)

Never, ever, been any trouble. Never, ever, been any confusion. Never,
ever, been any concern.

On the other hand, when I first took a stab at writing a simple "ping" app,
the complexity of wading through System.Net.Sockets to simply figure out how
to specify the IP address raised my blood pressure at least 30 points.

When .NET confronts you with a "fork in the road", it seems like there are
at least a dozen paths to choose. Not good.

[Patrick Troughton]

AFAIK, it doesn't matter whether the procedure is user-created or built-in
to the language. In VB6, all 7 rules apply equally. In VB.NET, there's still
only one rule. Unless you're trying to say that the rules change depending
on whether the procedure is user-created or built-in? If so, then the rules
governing VB6 procedure calling syntax are even more complicated that I thought...

/Pat

Dan Barclay <Dan@MVPs.org> wrote:
>Patrick,
>
>When Subs were introduced and allowed to be called without the Call
>keyword, the intent was to allow you to create "new statements". User
>defined extensions... good idea before their time, eh?
>
>The syntax for using a statement (whether you created it using Sub or
>it were a Basic statement) were the same.
>
> MyStatement Arg1, Arg2, Arg3 'yada yada
>
>So, now that we've established that it must be better to enclose
>argument lists in parens in all cases, should we now expect MS to
>change the syntax on the remainder of statements so that they use
>parens (yea, more like C). Yea, that sounds about right to me based
>on what they've done so far.
>
> Debug.Print("This Change Makes Sense:",False)
>
>>OK, you be the judge. Which procedure calling syntax do you think is easier
>>and why?
>
>OK, you be the judge. When you see the statement
>
> Printf (MyVar)
>
>is MyVar being passed "byval" or not? It depends on whether Printf is
>an internal keyword (you do remember them all don't you?)... as
>opposed to an explicit indicator like Call.
>
>YeaRight.
>
>Dan
>

[Dan Barclay]

Patrick,

When Subs were introduced and allowed to be called without the Call
keyword, the intent was to allow you to create "new statements". User
defined extensions... good idea before their time, eh?

The syntax for using a statement (whether you created it using Sub or
it were a Basic statement) were the same.

MyStatement Arg1, Arg2, Arg3 'yada yada

So, now that we've established that it must be better to enclose
argument lists in parens in all cases, should we now expect MS to
change the syntax on the remainder of statements so that they use
parens (yea, more like C). Yea, that sounds about right to me based
on what they've done so far.

Debug.Print("This Change Makes Sense:",False)

>OK, you be the judge. Which procedure calling syntax do you think is easier
>and why?

OK, you be the judge. When you see the statement

Printf (MyVar)

is MyVar being passed "byval" or not? It depends on whether Printf is
an internal keyword (you do remember them all don't you?)... as
opposed to an explicit indicator like Call.

YeaRight.

Dan



Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Frank Oquendo]

Dan Barclay had this to say:

> OK, you be the judge. When you see the statement
>
> Printf (MyVar)
>
> is MyVar being passed "byval" or not? It depends on whether Printf is
> an internal keyword (you do remember them all don't you?)... as
> opposed to an explicit indicator like Call.

Um... wouldn't that be defined by the function you're calling? And isn't
that as it should be? Your example points out the problem with such loose
rules: the code does not make itself immediately apparent. Modifiers such as
out and ref make it crystal clear how an argument is being passed.

--
"If you want to be somebody else change your mind"
http://www.acadx.com
http://vbxtender.sourceforge.net

[MMFAN]

I thought it was pretty funny myself.

"Frank Oquendo" <nospam@please.com> wrote:
>Patrick Troughton had this to say:
>
>> Here's another example where VB.NET is easier than VB6. If you're
>> joining us late, Tuesday we covered how creating a user control is
>> much easier in VB.NET.....
>
>That user control example was hilarious!
>
>--
>"If you want to be somebody else change your mind"
>http://www.acadx.com
>http://vbxtender.sourceforge.net
>
>

[MMFAN]

Ha you wish!

You fit right in with the rest of the poor scared .Netters who can't deal
with reasonable arguments. Weren't you compaining about all the negativity
in this discussion? Way to fuel the fire.

"Jens" <jens@esalar.be> wrote:
>Keep this up Patrick, I'm pretty sure that most NOTters will not respond
to
>this interesting series, since it is too technical for them. They might
>even finally understand things they have been doing all these years without
>knowing why.
>
>Jens
>
>

[Daniel Pratt]

Hi Dan,

"Dan Barclay" <Dan@MVPs.org> wrote in message
news8c5lu42r5k8kae7r6i3q1nnl8996n3le0@4ax.com...
> Patrick,
>
> When Subs were introduced and allowed to be called without the Call
> keyword, the intent was to allow you to create "new statements". User
> defined extensions... good idea before their time, eh?
>
> The syntax for using a statement (whether you created it using Sub or
> it were a Basic statement) were the same.
>
> MyStatement Arg1, Arg2, Arg3 'yada yada
>
> So, now that we've established that it must be better to enclose
> argument lists in parens in all cases, should we now expect MS to
> change the syntax on the remainder of statements so that they use
> parens (yea, more like C). Yea, that sounds about right to me based
> on what they've done so far.

You've just brought to mind yet another thing I think is a big
improvement in VB.NET (vs. VB6): No more statements with special syntax
rules like Mid, Write, Print and most abhorrently, Line (ironically,
intellisense would be exceptionally useful here but there is none). Of
course, there are still things like AddHandler and CType, which look a lot
like methods but aren't, but it's progress.

Regards,
Dan

[Frank Oquendo]

Dan Barclay had this to say:

> Nope, *you're* saying the rules change (require or don't require
> parens) depending on whether the precedure is user-created or built-in
> for VB.net so far as I can tell. But, maybe I misunderstood.

<quote>
Rule 1....Always Use Parenthesis.
</quote>

I think you misunderstood.

--
"If you want to be somebody else change your mind"
http://www.acadx.com
http://vbxtender.sourceforge.net

[Dan Barclay]

On 8 Aug 2002 11:04:05 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

>AFAIK, it doesn't matter whether the procedure is user-created or built-in
>to the language. In VB6, all 7 rules apply equally. In VB.NET, there's still
>only one rule.

Sorry, I don't follow your "new rules".

In VB6, if you see a statement without a Call keyword in front of it
then its argument list needs no parens surrounding it. That is the
case whether it's a built-in statement or a user Sub.

Sorry, but that seems *real* simple to me.

Now, the issue of whether an *individual argument* has parens around
it is a separate issue applied to each argument. If you want a copy
of the variable (or expression), you enclose an individual argument in
parens (aka "byval").

>Unless you're trying to say that the rules change depending
>on whether the procedure is user-created or built-in? If so, then the rules
>governing VB6 procedure calling syntax are even more complicated that I thought...

Nope, *you're* saying the rules change (require or don't require
parens) depending on whether the precedure is user-created or built-in
for VB.net so far as I can tell. But, maybe I misunderstood.

Dan


>Dan Barclay <Dan@MVPs.org> wrote:
>>Patrick,
>>
>>When Subs were introduced and allowed to be called without the Call
>>keyword, the intent was to allow you to create "new statements". User
>>defined extensions... good idea before their time, eh?
>>
>>The syntax for using a statement (whether you created it using Sub or
>>it were a Basic statement) were the same.
>>
>> MyStatement Arg1, Arg2, Arg3 'yada yada
>>
>>So, now that we've established that it must be better to enclose
>>argument lists in parens in all cases, should we now expect MS to
>>change the syntax on the remainder of statements so that they use
>>parens (yea, more like C). Yea, that sounds about right to me based
>>on what they've done so far.
>>
>> Debug.Print("This Change Makes Sense:",False)
>>
>>>OK, you be the judge. Which procedure calling syntax do you think is easier
>>>and why?
>>
>>OK, you be the judge. When you see the statement
>>
>> Printf (MyVar)
>>
>>is MyVar being passed "byval" or not? It depends on whether Printf is
>>an internal keyword (you do remember them all don't you?)... as
>>opposed to an explicit indicator like Call.
>>
>>YeaRight.
>>
>>Dan
>>

Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[MMFAN]

IF this is really what you guys wanted all along, then you should have just
used Pascal, C or Java... oh yeah those languages are hard to use.

"Frank Oquendo" <nospam@please.com> wrote:
>Dan Barclay had this to say:
>
>> OK, you be the judge. When you see the statement
>>
>> Printf (MyVar)
>>
>> is MyVar being passed "byval" or not? It depends on whether Printf is
>> an internal keyword (you do remember them all don't you?)... as
>> opposed to an explicit indicator like Call.
>
>Um... wouldn't that be defined by the function you're calling? And isn't
>that as it should be? Your example points out the problem with such loose
>rules: the code does not make itself immediately apparent. Modifiers such
as
>out and ref make it crystal clear how an argument is being passed.
>
>--
>"If you want to be somebody else change your mind"
>http://www.acadx.com
>http://vbxtender.sourceforge.net
>
>

[Patrick Troughton]

Dan Barclay <Dan@MVPs.org> wrote:
>On 8 Aug 2002 11:04:05 -0700, "Patrick Troughton"
><Patrick@Troughton.com> wrote:
>
>>AFAIK, it doesn't matter whether the procedure is user-created or built-in
>>to the language. In VB6, all 7 rules apply equally. In VB.NET, there's
still
>>only one rule.
>
>Sorry, I don't follow your "new rules".

I'm not sure what you mean. Are you talking about VB6 or VB.NET?

If VB.NET...there's only one rule.

If VB6...then there are several rules but they're not new. That's the way
it's been for years. And you *must* follow them if you want your VB6 code
to run.

In any case, they're not my rules. They're the compiler's rules.

>In VB6, if you see a statement without a Call keyword in front of it
>then its argument list needs no parens surrounding it.

I agree.

> That is the
>case whether it's a built-in statement or a user Sub.

I agree.

>Sorry, but that seems *real* simple to me.

Which part? Just rule 1 or all five (plus the two special cases)?

>Now, the issue of whether an *individual argument* has parens around
>it is a separate issue applied to each argument. If you want a copy
>of the variable (or expression), you enclose an individual argument in
>parens (aka "byval").

Correct. I mentioned that under VB6's rule 6 (special case of rule 2) and
VB6's rule 7 (special case of rule 4).

>Nope, *you're* saying the rules change (require or don't require
>parens) depending on whether the precedure is user-created or built-in
>for VB.net so far as I can tell.

No, I thought that's what you were trying to tell me.

>But, maybe I misunderstood.

Yes, I think we both did. In fact, I still don't understand what you were
trying to say. I guess the part that confused me is when you said....

<quote>
When you see the statement

Printf (MyVar)

is MyVar being passed "byval" or not? It depends on whether Printf is
an internal keyword (you do remember them all don't you?)... as
opposed to an explicit indicator like Call.
</quote>

Maybe I'm being dense but it sure sure sounds like you're saying that what
happens depends on whether it's an internal keyword or not.. What else does
"It depends on whether Printf is an internal keyword..." mean? Also, the
last part of your last sentence doesn't make any sense. You can use the Call
keyword to call a built-in function of VB6. For example...

Randomize
Call Randomize

Both of these compile just fine in VB6. Try it yourself.

/Pat