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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 17

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

  1. #1
    Dan Barclay Guest

    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.

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

  2. #2
    Larry Serflaten Guest

    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.

    LFS




  3. #3
    Zane Thomas Guest

    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:

    >I've heard of wearing blinders before


    Yes you have.


    --

    *--------={ Fine Art for .NET }=--------*
    | .Net Components @ www.abderaware.com |
    *---------------------------------------*

    Turn on, tune in, download.
    zane a@t abderaware.com

  4. #4
    Dan Barclay Guest

    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.

    VB6: syntax is consistent with Statement syntax (as originally
    designed)
    VB.Net: syntax is consistent with Call statement syntax.

    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.


    Indeed. I couldn't have said it better myself.

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

  5. #5
    Patrick Troughton Guest

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


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

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

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

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

    I provided cites from Visual Basic documentation to prove it.....

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

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

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

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

    Jeez, you need to learn to read.

    /Pat


  6. #6
    Dan Barclay Guest

    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.

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

  7. #7
    Larry Serflaten Guest

    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!

    That's fine with me....

    LFS



  8. #8
    Dan Barclay Guest

    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.

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

  9. #9
    Patrick Troughton Guest

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

    /Pat



  10. #10
    MMFAN Guest

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



  11. #11
    Larry Serflaten Guest

    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.

    LFS




  12. #12
    Dan Barclay Guest

    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.

    Note above the direct references to "procedure calling syntax", VB6,
    and VB.Net.

    What part of this do you not understand?

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

  13. #13
    Dan Barclay Guest

    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.

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

  14. #14
    Dan Barclay Guest

    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.

    There were no analogies, just plain fact.

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

  15. #15
    Larry Serflaten Guest

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

    "Dan Barclay" <Dan@MVPs.org> wrote in message
    > I went back to the earlier documentation to show, in plain English,
    > what the intent of the syntax was.


    VB was not unique in its ability to be enhanced.

    It seems to me that was everybody's marketing ploy at the time.
    'This language is cool because you can enhance it to suit your needs'
    type of thing, that had already been going on for years.

    I'd suspect that the intent was more about using the same parsing
    algorithms for user routines as they did with system calls. But you
    use their market speak as if it defined the language!

    Not very convincing to me....

    LFS







Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center