If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Son of VB6 vs VB.NET...Procedure Calling Syntax

On Sun, 11 Aug 2002 04:53:52 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:
>"Dan Barclay" <Dan@MVPs.org> wrote in message >
>> "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?"
>>
>> But I also refer you to the QB4 manual:
>>
>> =====quote======
>> A SUB procedure differs from a FUNCTION procedure in that a SUB cannot
>> be called by using its name within an expression. A call to a SUB is
>> a stand-alone statement, like BASIC's CIRCLE statement.
>> =====endquote===
>
>
>You seem to be arguing that you call user executable statements, just like
>VB's system executable statements. I get that from your last comment:

Yes, that was the intent when Call-less execution of Subs was
introduced. Perhaps we were too far ahead of our time for you to be
comfortable with, but facts are facts.

My point (which I've backed up with MS documentation) was that
Call-less procedure calls were designed to allow the user to create
statements with syntax like Basic's own statement syntax.

I've quoted documentation that explains this clearly. Is this somehow
unclear to you:

" 2. Use its name as a statement itself:"

I know it's subtle, but in case you missed it the clue here is "Use
its name as a statement itself:"
>> It still leaves the issue that now user defined executable statements
>> have a different syntax than system defined executable statements.
>
>But since you brought it up, can you create an executable statement like
>CIRCLE that seems to attach itself to a few objects, but never shows up
>in the object browser for those objects? What's that, VB does have a few
>system methods that are called differently than what you can create? Why
>then is it an issue for VB.Net? You know the ones I mean, Circle, Line,
>and Print.

The example MS used in the doc was the CIRCLE statement. In QB4
CIRCLE had only one context... the context of the PC screen, and it
was a straightforward statement.

However, the issue is statements and their syntax, not whether a
CIRCLE method is the same in VB.Net vs QB4. If you want to go down
that road do it with somebody else. I only quoted the doc regarding
syntax of "user statements".
>And its not just these.
>
>Show me how you would create a user executable command that acts just
>like Date and Time. One minute its a function, and the next a property!
>What's that? You can't do that? Then why is it an issue for VB.Net?

The issue isn't how you'd want to recreate existing system statements,
but how you'd create *your own statements for your own purposes*. If
you can create a procedure to do that, then you can make it a
statement. If you can't create a procedure to do that, then you can't
very well make it a statement, can you? The limitation isn't whether
you can make it a statement, but whether you can create the code to
accomplish the task.

So, you show me how to create a procedure to do those things, and I'll
show you how to make it a statement.

<snip>
>As I said before, IMO one advantage of using the parentheses is to help reduce the
>occurances of hard to find bugs, and that is in addition to being a *more consistant*
>format than VB6 allowed.

Nope, it's less consistent with VB.Net than with VB6.

In VB.Net user written procedures, used as executable statements,
require parenthesis around their argument list where built-in
executable statements do not. That this is less consistent is a
certainty.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

"Dan Barclay" <Dan@MVPs.org> wrote
> >> But I also refer you to the QB4 manual:
> >>
> >> =====quote======
> >> A SUB procedure differs from a FUNCTION procedure in that a SUB cannot
> >> be called by using its name within an expression. A call to a SUB is
> >> a stand-alone statement, like BASIC's CIRCLE statement.
> >> =====endquote===
> My point (which I've backed up with MS documentation) was that
> Call-less procedure calls were designed to allow the user to create
> statements with syntax like Basic's own statement syntax.
> >
> >Show me how you would create a user executable command that acts just
> >like Date and Time. One minute its a function, and the next a property!
> The issue isn't how you'd want to recreate existing system statements,
> but how you'd create *your own statements for your own purposes*.

I've heard of wearing blinders before, but this really shows the extend to which
you've close your own mind on the subject.

You bring forth outdated documentation and say its suppose to be accurate
for the current version, and when shown that VB has statements that cannot
be created by extending the language you say its not about recreating commands.

I didn't say I wanted to write (overload) new Date and Time routines, I said I
wanted *my own procedures* to act like the ones I mentioned.

After showing a half dozen or so of such inconsistancies in VB, you still
regurgitate that VB is more consistant than .Net, showing 1 or 2 examples of
supposedly inconsistant syntax, which were not shown in proper context anyway.

Since you think MS has quotable documentation, here is a quote that should
end the argument, once and for all:

<quote>
In Visual Basic.NET, parentheses are always required around a nonempty
argument list in any procedure call. In Sub calls, the Call statement is optional.
</quote>

That pretty well fits what Patrick was saying, and it is more current than the
documentation you dusted off and brought out.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

On Sun, 11 Aug 2002 19:42:34 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:
>"Dan Barclay" <Dan@MVPs.org> wrote
>
>> >> But I also refer you to the QB4 manual:
>> >>
>> >> =====quote======
>> >> A SUB procedure differs from a FUNCTION procedure in that a SUB cannot
>> >> be called by using its name within an expression. A call to a SUB is
>> >> a stand-alone statement, like BASIC's CIRCLE statement.
>> >> =====endquote===
>
>> My point (which I've backed up with MS documentation) was that
>> Call-less procedure calls were designed to allow the user to create
>> statements with syntax like Basic's own statement syntax.
>> >
>
>> >Show me how you would create a user executable command that acts just
>> >like Date and Time. One minute its a function, and the next a property!
>
>> The issue isn't how you'd want to recreate existing system statements,
>> but how you'd create *your own statements for your own purposes*.
>
>I've heard of wearing blinders before, but this really shows the extend to which
>you've close your own mind on the subject.

Closed *my* mind? My initial statement was what the *original*
concept was for calling Sub procedures without using the Call keyword.
I've stated what that is, and backed it up with Microsoft
documentation... yet you seem to still want to argue with it.

I've said before that regardless of which way it was initially, I the
real problem I have is with *changing* it once it's established. I've
further stated that in creating consistency between the Call syntax
and the non-Call syntax, they've broken consistency between the
initial "user statement" purpose and built-in statements.

None of what I've said before is incorrect. I haven't even argued
about which is best (other than to say "no reason to change it").
>You bring forth outdated documentation and say its suppose to be accurate
>for the current version, and when shown that VB has statements that cannot
>be created by extending the language you say its not about recreating commands.

Right, and the failure to consider "outdated documentation" is the
fundamental reason VB.Net is such a problem now. VB6 documentation is
outdated as well.

Regardless, the statement I made, and which you and Patrick decided to
argue, was about what the original intent of the syntax was. I am
correct about that, whether you accept it or not.
>After showing a half dozen or so of such inconsistancies in VB, you still
>regurgitate that VB is more consistant than .Net, showing 1 or 2 examples of
>supposedly inconsistant syntax, which were not shown in proper context anyway.

Are you purposely skewing this, or just not reading what I wrote? VB6
syntax is *as* consistent as VB.Net. It's just different. They
traded one inconsistency for another and made no progress.

In one case the "danger" is of someone making a single argument call
"ByVal" when they intended it to be "ByRef". In the other case the
"danger" is of someone making a single argument call "ByRef" when they
intended it to be "ByVal".

That is, no improvement came from this change and code was broken to
do it.
>Since you think MS has quotable documentation, here is a quote that should
>end the argument, once and for all:
>
><quote>
>In Visual Basic.NET, parentheses are always required around a nonempty
>argument list in any procedure call. In Sub calls, the Call statement is optional.
></quote>

With Visual Basic.NET they have, in fact, redefined the language. I
don't think anyone is arguing with that point (certainly not me).

My statement at the top was with regard to the *original* design of
the syntax which was retained from QB3 or 4 through VB6. I've stated
that and shown it in plain English documentation, yet you still refuse
to accept it.

It should not have been changed, but then that can be said about a lot
of things.
>I've heard of wearing blinders before, but this really shows the extend to which
>you've close your own mind on the subject.

Are you now willing to admit that you are wrong? Can you swallow your pride
and admit that AddHandler really is a statement, and isn't a procedure after
all?
>Are you purposely skewing this, or just not reading what I wrote? VB6
>syntax is *as* consistent as VB.Net. It's just different. They
>traded one inconsistency for another and made no progress.

Where in my OP did I say anything consistency? That was your point, not mine.
My point was about simplicity and ease of use.....

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

On 11 Aug 2002 19:41:06 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:
>
>Dan Barclay <Dan@MVPs.org> wrote:
>>Regardless, statement I made, and which you and Patrick decided to
>>argue, was what original intent of syntax was. I am
>>correct that, whether you accept it or not.
>
>No, I did not argue that at all. I said that AddHandler was a statement,
>not a procedure. I've said so several times....
<snip>
>Are you now willing to admit that you are wrong? Can you swallow your pride
>and admit that AddHandler really is a statement, and isn't a procedure after
>all?

What the *heck*are you talking about.

First, that's not what we were discussing (until you chose to take
some strange tangent). PLEASE note the title of this thread! Since
you started it I thought you might have a clue, but I guess not.

Second, if you want to discuss whether AddHandler is a procedure
(*executable* statement), ask Microsoft. I trust you will get the
correct answer (they know, whether you understand or not). What you
will likely learn is that AddHandler is a procedure that adds a
procedure entry point to a list. But, I don't claim to be the expert
on that (nor do I really care much) so ask MS.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

> I've said before that regardless of which way it was initially, I the
> real problem I have is with *changing* it once it's established. I've
> further stated that in creating consistency between the Call syntax
> and the non-Call syntax, they've broken consistency between the
> initial "user statement" purpose and built-in statements.

Your argument is about as logical as saying that the first radios were
built using tubes, that was the 'established' methods marketed to the
public, so they should still be required....

I have documentation that shows file asociations are to be done using
the File Manager Association dialog. Do you think that is also valid
information? That's how they 'intended' it to work.

Being able to 'extend' the language is still supported, and their statement
about calling user procedures in a manner similar to system commands
still holds true. But you admit above, that isn't the problem you have.
You indicate above that you are opposed to change.

In other words if they won't make it work the way you want, then
you won't play!

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

On Sun, 11 Aug 2002 23:43:56 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:
>> I've said before that regardless of which way it was initially, I the
>> real problem I have is with *changing* it once it's established. I've
>> further stated that in creating consistency between the Call syntax
>> and the non-Call syntax, they've broken consistency between the
>> initial "user statement" purpose and built-in statements.
>
>
>Your argument is about as logical as saying that the first radios were
>built using tubes, that was the 'established' methods marketed to the
>public, so they should still be required....

What kind of analogy is that? This has absolutely nothing to do with
what's "under the hood". If the volume is a turnable knob, it
generally increases the volume if you turn it to the right. Dunno
why, but maybe because they started that way? It doesn't matter if
it's a tube or single chip radio. Take a clue.
>I have documentation that shows file asociations are to be done using
>the File Manager Association dialog. Do you think that is also valid
>information? That's how they 'intended' it to work.

What does that have to do with language syntax or behavior? I don't
care if there is even a file manager association dialog at all... it
has nothing to do with this issue.
>Being able to 'extend' the language is still supported, and their statement
>about calling user procedures in a manner similar to system commands
>still holds true.

Yea? Using the same syntax for statements? Do tell.
>But you admit above, that isn't the problem you have.
>You indicate above that you are opposed to change.

You clearly took that out of context. I am not opposed to change at
all. I like playing with new toys as much as you do.

I am opposed to change in language syntax and behavior unless there is
good reason to do it because it's expensive for users, and I've never
been unclear about that so far as I know.

In this particular case (syntax for Call-less Sub calls), it's clear
that the change did not improve things and, in fact, only broke code.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

Dan Barclay <Dan@MVPs.org> wrote:
>
> First, that's not what we were discussing (until you chose to take
>some strange tangent). PLEASE note the title of this thread!

What bizarro world do you live in? The subject of this thread is VB6 vs VB.NET...Procedure
Calling Syntax. So far, you have done everything *but* discuss procedure
calling syntax. ****, you're not even talking about Visual Basic....

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

He's talking about VB you're just to dense to see it. The syntax he is speaking
of hadn't changed from Quick Basic to VB6.

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>Dan Barclay <Dan@MVPs.org> wrote:
>>
>> First, that's not what we were discussing (until you chose to take
>>some strange tangent). PLEASE note the title of this thread!
>
>What bizarro world do you live in? The subject of this thread is VB6 vs
VB.NET...Procedure
>Calling Syntax. So far, you have done everything *but* discuss procedure
>calling syntax. ****, you're not even talking about Visual Basic....
>
>/Pat
>
>

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

"Dan Barclay" <Dan@MVPs.org> wrote
> <serflaten@usinternet.com> wrote:
> >Your argument is about as logical as saying that the first radios were
> >built using tubes, that was the 'established' methods marketed to the
> >public, so they should still be required....
>
> What kind of analogy is that?

You're that one bringing out old documentation and saying it is still
relavent. So what if it sounded good, it is about as relavent as the
READ and DATA statements it contained.
> In this particular case (syntax for Call-less Sub calls), it's clear
> that the change did not improve things and, in fact, only broke code.

Back to the issue at hand, MS has removed the opportunity for that
ByVal but supposed to be ByRef, single parameter in parentheses, hard
to find bug. That is a change for the better, clearly an improvement.
If they did not accomplish that improvement, then explain how that
particular bug is still possible in VB.Net.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

On 12 Aug 2002 05:35:51 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:
>
>Dan Barclay <Dan@MVPs.org> wrote:
>>
>> First, that's not what we were discussing (until you chose to take
>>some strange tangent). PLEASE note the title of this thread!
>
>What bizarro world do you live in? The subject of this thread is VB6 vs VB.NET...Procedure
>Calling Syntax. So far, you have done everything *but* discuss procedure
>calling syntax. ****, you're not even talking about Visual Basic....

Let's take this again (with a short version) from the top.

1. The *procedure calling syntax* of VB6 (and before) allowed you
to *call the procedure* using a user defined statement syntax that
*called the procedure*. This syntax was identical to the syntax of
built-in executable statements that executed built-in procedures.

2. I have noted the change in syntax with VB.Net in which the
"user defined statement" form if the procedure call now requires
parenthesis such that its syntax is different from built-in executable
statements (which call internal procedures) and breaks code
originating in VB6

3. In order to convince you that this was the intended usage of
this syntax in VB6, I quoted you from previous documentation
(approximately the timeframe the feature was introduced to the
language) stating the intent of the syntax explicitly.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

On Mon, 12 Aug 2002 16:36:29 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:
>> In this particular case (syntax for Call-less Sub calls), it's clear
>> that the change did not improve things and, in fact, only broke code.
>
>Back to the issue at hand, MS has removed the opportunity for that
>ByVal but supposed to be ByRef, single parameter in parentheses, hard
>to find bug. That is a change for the better, clearly an improvement.
>If they did not accomplish that improvement, then explain how that
>particular bug is still possible in VB.Net.

This is a serious question: Can you still place parenthesis around
variables such that only their value is passed?

That is, in VB.Net:

DoThisThing ((ProtectThisVar))

Does this execute Sub DoThisThing and pass the value of ProtectThisVar
in such a way that DoThisThing can't change it?

If so, all they've done is exchanged one hard to find bug for another.
What's more, looking at a code fragment outside the context of the
version it came from does not show the intent of the code.

I suspect that you'll have just as many errors now in the opposite
direction. That is, someone writing

DoThisThing (ProtectThisVar)

and finding ProtectThisVar hosed.

Six of one, half dozen of the other. They made a *change*, but they
didn't make any improvement. They certainly didn't make the
substantial improvement that should be a hurdle for changing the
language.

Without thinking in the entire context of the language, they
apparently took the 'most frequently asked questions' list and
implemented what they could. There weren't any questions about this
being a problem the other way because it wasn't a problem...yet.

Re: Son of VB6 vs VB.NET...Procedure Calling Syntax

On Mon, 12 Aug 2002 16:36:29 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:
>"Dan Barclay" <Dan@MVPs.org> wrote
>> <serflaten@usinternet.com> wrote:
>> >Your argument is about as logical as saying that the first radios were
>> >built using tubes, that was the 'established' methods marketed to the
>> >public, so they should still be required....
>>
>> What kind of analogy is that?
>
>You're that one bringing out old documentation and saying it is still
>relavent. So what if it sounded good, it is about as relavent as the
>READ and DATA statements it contained.

I went back to the earlier documentation to show, in plain English,
what the intent of the syntax was. The documentation was from the
timeframe in which the feature was added to the language.