Son of VB6 vs VB.NET...Procedure Calling Syntax
On Sun, 11 Aug 2002 04:53:52 -0500, "Larry Serflaten"
>"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:
>> 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.
>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,
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.
>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
Language Stability is a *feature* I wish VB had!
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL