VB6 vs VB.NET...Procedure Calling Syntax

[Daniel Pratt]

Hi Dan,

"Dan Barclay" <Dan@MVPs.org> wrote in message
news:1lg5luggslh0bkir44opsdrr4764lgg7iq@4ax.com...
<snip>
> 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.

Well, its already more complicated than it needs to be and you haven't
mentioned the case of when you are assigning a return value to a variable,
which complicates it even further.

> 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").

At some point we have a function call like this:

If GetMyObject(myObjectVar) Then

myObjectVar.DoStuff

End If

At a later date we decide that GetMyObject needs to raise an error if
something goes wrong instead of returning False, so...<cut>...<cut>...

GetMyObject (myObjectVar)
myObjectVar.DoStuff

"Object or with variable not set." What the...! Oh yea, I forgot to
remove the parens, silly me.

Regards,
Dan

[Daniel Pratt]

Hi MMFAN,

"MMFAN" <mmf@mmf.org> wrote in message news:3d52c775$1@10.1.10.29...
>
> 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.

I like VB6 *despite* the syntax, not because of it.

Regards,
Dan

[Dan Barclay]

On Thu, 8 Aug 2002 14:19:39 -0500, "Frank Oquendo" <nospam@please.com>
wrote:

>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.

Like in:

Debug.Print (Expr1, Epr2, etc...)

Right?

Yea, that makes sense. Can't wait for the next round of language
changes to make it so. LOL

Dan

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

[Dan Barclay]

On Thu, 8 Aug 2002 15:50:26 -0400, "Daniel Pratt"
<dprREMOVETHISatt71@hotmail.com> wrote:

>Hi Dan,
>
>"Dan Barclay" <Dan@MVPs.org> wrote in message
>news:1lg5luggslh0bkir44opsdrr4764lgg7iq@4ax.com...
><snip>
>> 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.
>
> Well, its already more complicated than it needs to be and you haven't
>mentioned the case of when you are assigning a return value to a variable,
>which complicates it even further.

In case you haven't figured it out yet: Neither environments are
completely consistent. It's a matter of what you choose to attach
your need for consistency to.

Changing the way it behaves didn't improve anything, it only changed
it.

Maybe in the next round of changes they'll make everything consistent
(nobody will mind rewriting again from what I can surmise). Then
again, maybe the next round will only be a hodgepodge of changes like
this one.

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

[Daniel Pratt]

Hi Dan,

"Dan Barclay" <Dan@MVPs.org> wrote in message
news:a4l5luk2ls9oq64s9obm5q3uvj4nte7ll6@4ax.com...
>
> In case you haven't figured it out yet: Neither environments are
> completely consistent. It's a matter of what you choose to attach
> your need for consistency to.

I pointed out some (of what I consider to be) inconsistencies within
VB.NET in a recent post. Btw, you seem to be alluding (in your typically
obtuse fashion) to a particular inconsistency in VB.NET having to do with
procedure calls. Please elucidate.

> Changing the way it behaves didn't improve anything, it only changed
> it.

I consider that *more* consistent is better.

> Maybe in the next round of changes they'll make everything consistent
> (nobody will mind rewriting again from what I can surmise). Then
> again, maybe the next round will only be a hodgepodge of changes like
> this one.

I don't consider that making major changes to a language every version
is wise, but neither do I think that maintaining 100% compatibility with all
previous versions is wise. Well, more correctly, I think that there is a
place for nearly 100% backwords compatible languages, but clearly VB does
not attempt to fill that niche.

Regards,
Dan

[Dan Barclay]

On Thu, 8 Aug 2002 17:18:15 -0400, "Daniel Pratt"
<dprREMOVETHISatt71@hotmail.com> wrote:

>> In case you haven't figured it out yet: Neither environments are
>> completely consistent. It's a matter of what you choose to attach
>> your need for consistency to.
>
> I pointed out some (of what I consider to be) inconsistencies within
>VB.NET in a recent post. Btw, you seem to be alluding (in your typically
>obtuse fashion) to a particular inconsistency in VB.NET having to do with
>procedure calls. Please elucidate.

Yea, what I posted was obtuse to folks that want to ignore it:
======================
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)
======================

>> Changing the way it behaves didn't improve anything, it only changed
>> it.
>
> I consider that *more* consistent is better.

But it is *less* consistent with respect to statement syntax. A clue
from my statement above "It's a matter of what you choose to attach
your need for consistency to."

>> Maybe in the next round of changes they'll make everything consistent
>> (nobody will mind rewriting again from what I can surmise). Then
>> again, maybe the next round will only be a hodgepodge of changes like
>> this one.
>
> I don't consider that making major changes to a language every version
>is wise, but neither do I think that maintaining 100% compatibility with all
>previous versions is wise.

Maintaining compatibility unless there is a clear reason to change it
should be the objective. You say I'm obtuse, but I don't know how to
be any more clear than http://www.mvps.org/vb/tips/stability.htm

>Well, more correctly, I think that there is a
>place for nearly 100% backwords compatible languages,

Right. Languages you intend to use for mission critical "legacy"
applications. Languages you intend to build libraries of code with.

>but clearly VB does
>not attempt to fill that niche.

Ya Think??!?! You get the "perceptive statement of the day" award.

That's not what Microsoft told us before. VB was billed as a "real
development environment" suitable for writing mission critical "new
legacy" applications.

They've broken that promise.

It is *now* clear that Microsoft does not consider VB to be in that
niche, I agree. That's why I've said that VB is suitable only for
"throwaway code" applications. Prototyping and scripting.

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

[Patrick Troughton]

Dan Barclay <Dan@MVPs.org> wrote:
>On Thu, 8 Aug 2002 17:18:15 -0400, "Daniel Pratt"
><dprREMOVETHISatt71@hotmail.com> wrote:
>
>
>Yea, what I posted was obtuse to folks that want to ignore it:

No, you're just doing a poor job of explaining yourself. We're asking nicely
for elaboration. Being rude isn't scoring you any points.

>======================
>So, now that we've established that it must be better to enclose
>argument lists in parens in all cases,

Just to be clear, my point was not that parens were better. My point was
to compare VB6's 5 syntax rules (plus 2 special cases) for when to use parens
around arguments versus VB.NET's 1 rule. There's a misperception among some
people that VB.NET is somehow harder to learn than VB6. What I am trying
to do is to educate people on the differences between the two languages.


>should we now expect MS to
>change the syntax on the remainder of statements so that they use
>parens (yea, more like C).

They've already done that. The syntax for calling routines in VB.NET is consistant
AFAIK. Are you saying that you're aware of some exception to the rule? Maybe
there is an exception...I don't know...but off the top of my head I can't
think of one. Did you want us to keep playing this guessing game or will
you just tell us?

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

The syntax for using Debug *is* consistant with VB.NET's 1 rule standard.
Example...

Debug.Write("VB.NET is easy to learn and makes programming fun again!")

BTW, there is no overloaded version of the Write method that accepts a boolean
as the second parameter as your example shows. Are you trying to be funny?


/Pat

[Dan Barclay]

On 8 Aug 2002 15:48:34 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

>>
>>Yea, what I posted was obtuse to folks that want to ignore it:
>
>No, you're just doing a poor job of explaining yourself. We're asking nicely
>for elaboration. Being rude isn't scoring you any points.
>
>>======================
>>So, now that we've established that it must be better to enclose
>>argument lists in parens in all cases,
>
>Just to be clear, my point was not that parens were better. My point was
>to compare VB6's 5 syntax rules (plus 2 special cases) for when to use parens
>around arguments versus VB.NET's 1 rule.

>There's a misperception among some
>people that VB.NET is somehow harder to learn than VB6. What I am trying
>to do is to educate people on the differences between the two languages.

I can't (and therefore won't) argue one way or the other about which
is easier. My point regarding parens was that it adds consistency
from one point of view, and reduces consistency from another point of
view.

If it makes it easier for you, so be it. However, the change didn't
result in a net improvement, it only resulted in change. That being
the case, the default position they should have taken on it would have
been to leave it as it was.

I'm not arguing that one way is better than the other...I'd say that
even if it started out the other way. *Both* methods are inconsistent
from one point of view or the other.

>>should we now expect MS to
>>change the syntax on the remainder of statements so that they use
>>parens (yea, more like C).
>
>They've already done that. The syntax for calling routines in VB.NET is consistant
>AFAIK. Are you saying that you're aware of some exception to the rule? Maybe
>there is an exception...I don't know...but off the top of my head I can't
>think of one. Did you want us to keep playing this guessing game or will
>you just tell us?

OK, try this. Go to VB.NetHelp|LanguageReference|Statements.

Now, pick statements that take arguments and look at some examples
(starting at the top of what I have):

AddHandler Obj.Ev_Event, AddressOf EventHandler ' invisible parens!
Erase Int3DArray, Int2DArray ' and again here. Cool!
etc, etc.

Oh, and here's a really cool one:

Return "Infant"

Do you see any parens around the arguments on those statements? Any?

These statements don't require parens around the argument list (or did
I misconstrue something here?). Yet, our own statements now require
parens when they did not previously require them.

How am I not being clear?

>
>> Debug.Print("This Change Makes Sense:",False)
>
>The syntax for using Debug *is* consistant with VB.NET's 1 rule standard.
>Example...
>
>Debug.Write("VB.NET is easy to learn and makes programming fun again!")
>
>BTW, there is no overloaded version of the Write method that accepts a boolean
>as the second parameter as your example shows. Are you trying to be funny?

My bad. I'd forgot that VB.Net didn't have the debug.print method.
Using the old Print method allowed you to put whatever you wanted (and
more than one) as arguments.

The issue regards statements and the usage of parents around statement
arguments. See above. To be consistent, I presume we need to now
change the syntax of those statements to be more like:

AddHandler (Obj.Ev_Event, AddressOf EventHandler)
Erase (Int3DArray, Int2DArray)
Return ("Infant")

Dan (also waiting on End For)
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Patrick Troughton]

Hi Dan,

I must say that I am dissappointed in you. You know as well as I do that
AddressOf is an *operator* not a procedure. AddressOf is no different than
+, *, - or Like. You don't require parens around after a plus sign or division
sign, do you? And please, don't try to plead ignorance because AddressOf
was an operator in VB6, too. That hasn't changed. The same goes for the rest
of your points since none of them are procedures. I can't believe you tried
that. You should know better.

/Pat

Dan Barclay <Dan@MVPs.org> wrote:
>On 8 Aug 2002 15:48:34 -0700, "Patrick Troughton"
><Patrick@Troughton.com> wrote:
>
>>>
>>>Yea, what I posted was obtuse to folks that want to ignore it:
>>
>>No, you're just doing a poor job of explaining yourself. We're asking nicely
>>for elaboration. Being rude isn't scoring you any points.
>>
>>>======================
>>>So, now that we've established that it must be better to enclose
>>>argument lists in parens in all cases,
>>
>>Just to be clear, my point was not that parens were better. My point was
>>to compare VB6's 5 syntax rules (plus 2 special cases) for when to use
parens
>>around arguments versus VB.NET's 1 rule.
>
>>There's a misperception among some
>>people that VB.NET is somehow harder to learn than VB6. What I am trying
>>to do is to educate people on the differences between the two languages.
>
>I can't (and therefore won't) argue one way or the other about which
>is easier. My point regarding parens was that it adds consistency
>from one point of view, and reduces consistency from another point of
>view.
>
>If it makes it easier for you, so be it. However, the change didn't
>result in a net improvement, it only resulted in change. That being
>the case, the default position they should have taken on it would have
>been to leave it as it was.
>
>I'm not arguing that one way is better than the other...I'd say that
>even if it started out the other way. *Both* methods are inconsistent
>from one point of view or the other.
>
>>>should we now expect MS to
>>>change the syntax on the remainder of statements so that they use
>>>parens (yea, more like C).
>>
>>They've already done that. The syntax for calling routines in VB.NET is
consistant
>>AFAIK. Are you saying that you're aware of some exception to the rule?
Maybe
>>there is an exception...I don't know...but off the top of my head I can't
>>think of one. Did you want us to keep playing this guessing game or will
>>you just tell us?
>
>OK, try this. Go to VB.NetHelp|LanguageReference|Statements.
>
>Now, pick statements that take arguments and look at some examples
>(starting at the top of what I have):
>
> AddHandler Obj.Ev_Event, AddressOf EventHandler ' invisible parens!
>Erase Int3DArray, Int2DArray ' and again here. Cool!
> etc, etc.
>
>Oh, and here's a really cool one:
>
> Return "Infant"
>
>Do you see any parens around the arguments on those statements? Any?
>
>These statements don't require parens around the argument list (or did
>I misconstrue something here?). Yet, our own statements now require
>parens when they did not previously require them.
>
>How am I not being clear?
>
>>
>>> Debug.Print("This Change Makes Sense:",False)
>>
>>The syntax for using Debug *is* consistant with VB.NET's 1 rule standard.
>>Example...
>>
>>Debug.Write("VB.NET is easy to learn and makes programming fun again!")
>>
>>BTW, there is no overloaded version of the Write method that accepts a
boolean
>>as the second parameter as your example shows. Are you trying to be funny?
>
>My bad. I'd forgot that VB.Net didn't have the debug.print method.
>Using the old Print method allowed you to put whatever you wanted (and
>more than one) as arguments.
>
>The issue regards statements and the usage of parents around statement
>arguments. See above. To be consistent, I presume we need to now
>change the syntax of those statements to be more like:
>
>AddHandler (Obj.Ev_Event, AddressOf EventHandler)
>Erase (Int3DArray, Int2DArray)
>Return ("Infant")
>
>Dan (also waiting on End For)
>Language Stability is a *feature* I wish VB had!
> (#6)
>Error 51
>Error 3
>Error 9
>....

[Frank Oquendo]

Patrick Troughton had this to say:

> I must say that I am dissappointed in you. You know as well as I do
> that AddressOf is an *operator* not a procedure. AddressOf is no
> different than +, *, - or Like. You don't require parens around after
> a plus sign or division sign, do you? And please, don't try to plead
> ignorance because AddressOf was an operator in VB6, too. That hasn't
> changed. The same goes for the rest of your points since none of them
> are procedures. I can't believe you tried that. You should know
> better.

AddHandler is a statement and it doesn't require any parens. Why is that?

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

[Mike Mitchell]

On 8 Aug 2002 15:48:34 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

>........ There's a misperception among some
>people that VB.NET is somehow harder to learn than VB6.

There's a misperception among some Eskimos that they don't need
freezers. There's a misperception among some young, reckless drivers
that driving while drunk and stoned won't get them killed. There's a
misperception among lemmings that cliffs are the only way out.

MM

[Mike Mitchell]

On Thu, 08 Aug 2002 22:14:00 -0500, Dan Barclay <Dan@MVPs.org> wrote:

>How am I not being clear?

By not agreeing with him!

MM

[Patrick Troughton]

"Frank Oquendo" <nospam@please.com> wrote:
>Patrick Troughton had this to say:
>
>
>AddHandler is a statement and it doesn't require any parens. Why is that?
>

That answer is in the question. It's a statement, not a procedure.

/Pat

[Daniel Pratt]

Hi Frank,

"Frank Oquendo" <nospam@please.com> wrote in message
news:3d53379e@10.1.10.29...
<snip>
> AddHandler is a statement and it doesn't require any parens. Why is that?

I think that it should, which is why I mentioned it as one of VB.NET's
inconsistencies in a prior post. I (obviously) don't think that VB.NET
doesn't have its own inconsistencies, but there are far less than in VB6. As
I said before, more consistency is better.

Regards,
Dan

[Patrick Troughton]

From the VB6 help files...

<QUOTE>
AddressOf Operator

A unary operator that causes the address of the procedure it precedes to
be passed to an API procedure that expects a function pointer at that position
in the argument list.
</QUOTE>

/Pat

Dan Barclay <Dan@MVPs.org> wrote:
>On 8 Aug 2002 20:23:55 -0700, "Patrick Troughton"
><Patrick@Troughton.com> wrote:
>
>>
>>Hi Dan,
>>
>>I must say that I am dissappointed in you. You know as well as I do that
>>AddressOf is an *operator* not a procedure. AddressOf is no different than
>>+, *, - or Like. You don't require parens around after a plus sign or division
>>sign, do you? And please, don't try to plead ignorance because AddressOf
>>was an operator in VB6, too. That hasn't changed.
>
>What the *heck* are you talking about. In what I quoted AddressOf was
>used as an argument to the statement AddHandler. This was cut/pasted
>directly from VB.Net help on that statement.
>
>The point, as clearly shown, is that VB statements (internal
>procedures) do not require parens around their arguments... which is
>inconsistent with user statements (for user procedures) that do.
>
>Perhaps Mr Pratt can explain this to you better.
>
>>The same goes for the rest
>>of your points since none of them are procedures. I can't believe you tried
>>that. You should know better.
>
>Each of those statements executes a built in procedure. The the
>difference is who wrote the procedure.
>
>Dan
>
>Language Stability is a *feature* I wish VB had!
> (#6)
>Error 51
>Error 3
>Error 9
>....