Re: Editorial by Russell Jones/Attack on Gosub - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 7 FirstFirst 1234 ... LastLast
Results 16 to 30 of 91

Thread: Re: Editorial by Russell Jones/Attack on Gosub

  1. #16
    Dan Barclay Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    On Sat, 27 Jan 2001 01:02:43 -0500, "Steve Dee"
    <Steve_Dee@md.prestige.net> wrote:

    >Dan,
    > C++ and C have always had a way to do Gosub/Return (in a matter of
    >speaking). Typically it is an inline macro though...or back in the olden
    >days you would use a longjump. Does that mean it's a good thing? No...and
    >it wasn't and isn't a good thing in BASIC.


    Macro could be a GoodThing, and if done right could possibly take the
    place of GoSub... particularly if they made it with multiple entry
    points. Macro could bloat the executable, but with as much baggage as
    we have these days it may not be noticed.

    >It's just a holdover from line
    >basic, when we didn't have functions or subroutines.


    Nope. Still used. It should be provided in all high level languages.

    >It's just basically
    >BAD STYLE and is NOT faster,more efficient, or more understandable.


    Did someone appoint you Style Judge? It is *far* easier to read code
    if you use GoSub properly. GoSub stopped being more efficient about
    VB4 as I recall. Prior to that it was much faster than a Call. In
    fact, in the DOS compilers GoSub compiled to an ASM Call/Ret pair.

    >You
    >have a lot of (real) issues to complain about, don't complain about crap
    >that should have gone away years ago.


    If you don't use GoSub, then it shouldn't bother you. If it's
    crap-code when you get through with it then you apparently *should*
    leave it alone. GoSub is just another flow control tool and, more to
    the point, it is a fundamental part of the Basic Language. You can
    use it or abuse it like any other tool. But, without it the language
    isn't Basic.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)

  2. #17
    Jeff Peil Guest

    Re: Editorial by Russell Jones/Attack on Gosub


    "Dan Barclay" <dbarclay@ih2000.net> wrote in message
    news:c5a77t4qpur6ve7a8e3qm1nppglpdbcf9t@4ax.com...
    >
    > Macro could be a GoodThing, and if done right could possibly take the
    > place of GoSub... particularly if they made it with multiple entry
    > points. Macro could bloat the executable, but with as much baggage as
    > we have these days it may not be noticed.


    If you ask me, function-like macros are often abused, miunderstood, and a
    cause of many erros that are very hard to detect when reading the code.
    They *are not* functions, C++ took a much better road with the concept of
    inline functions (where you basically are explicitly asking the compiler to
    consider inlining a function.) Just to give a good example, one of the more
    prominent C++ compiler verification suites recently released an update that
    broke ~5 of their tests because they had a function-like macro that looked
    roughly like

    #define funcmacro(a, b) somecall( (void*)a, (void*)b)

    and then they roughly used in it their tests like

    funcmacro(var1 + sizeof(sometype), var2 + sizeof(someothertype));

    Which after expanding from the preprocessor looks to the parser like

    somecall((void*)var1 + sizeof(sometype), (void*)var2 +
    sizeof(someothertype));

    This of course doesn't work because the usage of the macro expects the
    arguments to be evaluated *before* the cast to a void*, and instead the
    first portion of each are is cast to a void* and then the addition is
    attempted.

    The point is, these are tests being written by people to test standards
    compliance, so they should have a decent understanding of the language, and
    yet they still make this type of error when using function-macros.

    > Nope. Still used. It should be provided in all high level languages.


    I'm not going to tell you it doesn't belong in basic, but I think that "all
    high level languages" is far from accurate.

    Personally I believe that there are more elegant mechanisms that a language
    can provide, for both goto and gosub in places they are traditionally used
    (though I will conceed that there are, at least for goto, a few cases where
    it can be a reasonable choice but that's primarily in highly optimized code,
    such as heap management routines used in a runtime library, but removing it
    from a language as was done with Java is not terribly limiting even when
    optimizing*)

    *Of course with more modern processors and compilers, this is even less of
    an issue, as they can usually generate near optimal code using other flow
    control structures that have better scoping rules.

    > If you don't use GoSub, then it shouldn't bother you. If it's
    > crap-code when you get through with it then you apparently *should*
    > leave it alone. GoSub is just another flow control tool and, more to
    > the point, it is a fundamental part of the Basic Language. You can
    > use it or abuse it like any other tool. But, without it the language
    > isn't Basic.


    I think you could say that about a lot of things even in traditional MS
    Basic, it is not ANSI Basic.

    It is fair to say that this is one reason why VB.NET, the language, is not
    the language used in VB6. However, if you consider all the variants of
    Basic out their that all include basic in their name I don't see how you can
    point at one language flow control mechanism and say "to be Basic it must
    have this"




  3. #18
    Jeff Peil Guest

    Re: Editorial by Russell Jones/Attack on Gosub


    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
    in message news:3a73fbf4$1@news.devx.com...
    >
    > Adding language features and then dropping them without even adding a
    > version or three to deprecate them effectively is a BAD thing. Because
    > people need time to handle the inertia of these large projects, steering
    > them on a new course. THAT is why language stability IS a feature!
    >


    MichKa,

    Understand I'm a big proponent of language stability. I don't disagree with
    your points, however I don't see why they apply?

    My point was that Dan has every right to call the removal of gosub when
    moving between VB6 and VB.NET enough of a change to make the languages
    different.

    However, I don't think that it alone can be pointed at as the *defining*
    feature of languages considered to be dialects of Basic (IOW, if you took
    VB6 and just removed gosub support, I think you'd have a hard time making
    the cas ethat it is no longer a dialect of Basic.)



  4. #19
    Mark Burns Guest

    Re: Editorial by Russell Jones/Attack on Gosub


    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
    in message news:3a7486df$1@news.devx.com...
    > How many changes would it take to deserve the label of ~BASIC? 1000? 500?
    > 200? 100? 50? 10?


    Hmmm...sounds like the age-olde "How many Angels can dance on the head of a
    pin?" merry-go-round.

    > It seems like there is a biblical precedent for this one in Genesis, is
    > there not?Abraham arguing with God about backwards compatibility with the
    > programs running in Sodom or somesuch? <g>


    Hoo boy...when you stretch to make a point, you r-e-a-l-l-y like to
    s---t---r---e---t---c---h quite a distance to make it doncha?<g>



  5. #20
    Mark Burns Guest

    Re: Editorial by Russell Jones/Attack on Gosub


    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
    in message news:3a7491f8$1@news.devx.com...
    > "Mark Burns" <mark@iolofpa.com> wrote in message
    > news:3a748c73@news.devx.com...
    >
    > > Hoo boy...when you stretch to make a point, you r-e-a-l-l-y like to
    > > s---t---r---e---t---c---h quite a distance to make it doncha?<g>

    >
    > Ah, well I think they changed the scenario of the argument so that
    > non-programmers would understand it when it was laid out in the bible,

    thats
    > all. They simplified it from "good programmers vs. poor programmers" into
    > righteous vs. wicked/evil. So they sent out those three consultants to

    raze
    > the project.
    >
    > Any Christian will point out that programming has been an interest ever
    > since it became clear how important it was that Jesus saves. <vbseg>
    >
    > (well, slightly bored and it is Sunday!)


    Well for pity's sake...log off and go watch the Superbowl pre-game
    as-nauseum hype shows for a while...before you _embarrass_ yourself!<bg>




  6. #21
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in message <news:3a73fbf4$1@news.devx.com>...

    > Adding language features and then dropping them without even adding a
    > version or three to deprecate them effectively is a BAD thing. Because
    > people need time to handle the inertia of these large projects, steering
    > them on a new course. THAT is why language stability IS a feature!


    You wussie. REAL PROGRAMMERS can redesign and rewrite megaline mission-
    critical apps overnight, anywhere, anytime. Either that or they finagle
    a promotion out of the trenches ASAP!

    --
    Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  7. #22
    David Bayley Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    > But a lot of people are going to be hurt by this nonsense.

    The port is painful yes, but the reasons being advocated are being blown out
    of proportion.

    I say that from experience of porting VB5 apps to C#, where the "gratuitous
    incompatibilities" of VB.NET are nothing by comparison! All the logic ports
    over easily. The vast majority of testing and bug ironing I did in VB5, is
    carried over to the new C# versions easily. The syntax differences really
    aren't the problem.

    The pain comes from porting to the new frameworks and platform, and
    re-designing to take advantage of implementation inheritance. From a
    business point of view, porting to .NET should only be done to take
    advantage of these features.

    Having said that, I agree that the gratuitous incompatibilities will make
    maintaining parallel code bases in VB5 and VB.NET frustrating. So IMO,
    things like Wend/EndWhile and Integer/Long ain't worth it, whereas BitOr and
    System.Boolean are. I also agree that dumping Gosub is well out of order,
    let alone not deprecating it first.

    In short, they could've made it less painful, but far from painless.

    --
    David.




  8. #23
    Dan Barclay Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    On Sun, 28 Jan 2001 01:56:26 -0800, "Jeff Peil" <jpeil@bigfoot.com>
    wrote:

    >
    >"Dan Barclay" <dbarclay@ih2000.net> wrote in message
    >news:c5a77t4qpur6ve7a8e3qm1nppglpdbcf9t@4ax.com...
    >>
    >> Macro could be a GoodThing, and if done right could possibly take the
    >> place of GoSub... particularly if they made it with multiple entry
    >> points. Macro could bloat the executable, but with as much baggage as
    >> we have these days it may not be noticed.

    >
    >If you ask me, function-like macros are often abused, miunderstood, and a
    >cause of many erros that are very hard to detect when reading the code.


    I would guess that's right. After sleeping on the Macro as a
    replacement for Gosub thing, I'm not so confident it would work.
    FWIW, I was thinking of it more in terms of a code fragment
    substitution ("named" Include?) rather than a call-like-thing. I
    think that would work, except that you'll find that GoSubs with
    multiple exit points (and even entry points) are sometimes used.

    Actually I guess even that could be implemented if the compiler used
    pseudo labels. Yea, I'm pretty sure that would work... an easy fix
    for the compiler and the code would look exactly the same to us.

    >They *are not* functions, C++ took a much better road with the concept of
    >inline functions (where you basically are explicitly asking the compiler to
    >consider inlining a function.) Just to give a good example, one of the more
    >prominent C++ compiler verification suites recently released an update that
    >broke ~5 of their tests because they had a function-like macro that looked
    >roughly like
    >
    >#define funcmacro(a, b) somecall( (void*)a, (void*)b)
    >
    >and then they roughly used in it their tests like
    >
    >funcmacro(var1 + sizeof(sometype), var2 + sizeof(someothertype));
    >
    >Which after expanding from the preprocessor looks to the parser like
    >
    >somecall((void*)var1 + sizeof(sometype), (void*)var2 +
    >sizeof(someothertype));
    >
    >This of course doesn't work because the usage of the macro expects the
    >arguments to be evaluated *before* the cast to a void*, and instead the
    >first portion of each are is cast to a void* and then the addition is
    >attempted.


    Of course, with Basic there are no parameters on GoSubs, so it's just
    a inlining code. BUT, the gosub definitions are only valid within the
    procedure scope.

    >The point is, these are tests being written by people to test standards
    >compliance, so they should have a decent understanding of the language, and
    >yet they still make this type of error when using function-macros.


    You'd think so <g>.

    >> Nope. Still used. It should be provided in all high level languages.

    >
    >I'm not going to tell you it doesn't belong in basic, but I think that "all
    >high level languages" is far from accurate.
    >
    >Personally I believe that there are more elegant mechanisms that a language
    >can provide, for both goto and gosub in places they are traditionally used
    >(though I will conceed that there are, at least for goto, a few cases where
    >it can be a reasonable choice but that's primarily in highly optimized code,
    >such as heap management routines used in a runtime library, but removing it
    >from a language as was done with Java is not terribly limiting even when
    >optimizing*)


    Many times there are more elegant solutions with just the options we
    have in Basic. Sometimes not. When you have a hammer, everything is
    not a nail. Does't mean the hammer isn't useful sometimes.

    >*Of course with more modern processors and compilers, this is even less of
    >an issue, as they can usually generate near optimal code using other flow
    >control structures that have better scoping rules.


    Of course, we're talking about this from the language standpoint. The
    compiler could do all sorts of things "under the hood" to implement
    and then optimize the emitted code.

    >> If you don't use GoSub, then it shouldn't bother you. If it's
    >> crap-code when you get through with it then you apparently *should*
    >> leave it alone. GoSub is just another flow control tool and, more to
    >> the point, it is a fundamental part of the Basic Language. You can
    >> use it or abuse it like any other tool. But, without it the language
    >> isn't Basic.

    >
    >I think you could say that about a lot of things even in traditional MS
    >Basic, it is not ANSI Basic.


    I was too broad. In the context of the discussion I was thinking "MS
    Basic". That is not the same as ANSI Basic as you point out. For
    developers on this path, the MS Basic de-facto standard is the measure
    of compliance.

    >It is fair to say that this is one reason why VB.NET, the language, is not
    >the language used in VB6. However, if you consider all the variants of
    >Basic out their that all include basic in their name I don't see how you can
    >point at one language flow control mechanism and say "to be Basic it must
    >have this"


    Agreed. I'm speaking from the point of view of a developer who's used
    and counted on the MS Basic language since dirt was invented.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)

  9. #24
    Karl E. Peterson Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    Hi Patrick --

    Class methods weren't a suitable alternative either, necessarily. There's overhead
    with those that goes far beyond the IP push. (Just to emphasize, this is
    "over-the-top" tuning, for routines that just can't be squeezed any other way.)

    Later... Karl
    --
    http://www.mvps.org/vb


    "Patrick Steele" <psteele@ipdsolution.com_> wrote in message
    news:MPG.14dcd64fba32c5ab989694@news.devx.com...
    > In article <MPG.14dcd2b04bb7ba7298968b@news.devx.com>,
    > drothgery@myrealbox.com says...
    > > Patrick Steele <psteele@ipdsolution.com_> wrote:
    > > >
    > > > True, but his example did at least show a form of encapsulation.
    > > >
    > > > With global access, any function within the module/class will have the
    > > > potential to muck with the values.

    > >
    > > Well, yeah.
    > > But what's the point of putting functions in an object if they're not
    > > supposed to work on the same [presumably private to the object] data?

    >
    > Ok. I was under the impression that this was older VB code (pre-VB4) and
    > he didn't have access to classes. In that situation, the GOSUB really
    > gave a decent form of encapsulating the data within that one function
    > (which may have been inside a huge, global .BAS module).
    >
    > But if this was post VB3, then I agree with you. It probably would have
    > been more efficient to move it into a class.
    >
    > --
    > Patrick Steele
    > (psteele@ipdsolution.com)
    > Lead Software Architect



  10. #25
    Patrick Steele Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    In article <3a75dc39$1@news.devx.com>, karl@mvps.org says...
    > Hi Patrick --
    >
    > Class methods weren't a suitable alternative either, necessarily. There's overhead
    > with those that goes far beyond the IP push. (Just to emphasize, this is
    > "over-the-top" tuning, for routines that just can't be squeezed any other way.)


    Yes. I had the performance issue in mind when I said:

    > > It probably would have
    > > been more efficient to move it into a class.


    "probably would have been" -- Since I didn't know the whole situation, I
    didn't want to pin myself down to a "it SHOULD have been converted". See
    -- I can learn from my mistakes of spouting off too quickly <g>

    If you need a "fast as possible" solution, the overhead of instantiating
    and manipulating an object would be a negative.

    --
    Patrick Steele
    (psteele@ipdsolution.com)
    Lead Software Architect

  11. #26
    Steve Dee Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    Dan,
    > the point, it is a fundamental part of the Basic Language. You can
    > use it or abuse it like any other tool. But, without it the language
    > isn't Basic.


    Visual Basic hasn't been "Basic" in the classic sense for a long time. You
    know that.

    > Did someone appoint you Style Judge? It is *far* easier to read code
    > if you use GoSub properly. GoSub stopped being more efficient about


    Well yes they did...but not the "Style Judge" of the world. Sometimes it's
    hard to get my day job out of my "newsgroup" posts. Part of my job (among
    other things) for the past 10 years has been to be the "Style Judge/Code
    Cop, etc." Someone must think it is worthwhile or people would quit
    recruiting me away from places.

    I really don't think that Gosub is easier to read, even if used "properly".
    I also think it's a bad idea to expose new programmers to something that the
    language dealer (for years) has told us is going away someday.

    > VB4 as I recall. Prior to that it was much faster than a Call. In
    > fact, in the DOS compilers GoSub compiled to an ASM Call/Ret pair.


    Sure it was...did the speed alone mean it was a good thing? I think
    not....and it was more than likely a jmp/ret pair. But if you wanted pure
    speed with jmp/ret, why not DO it in Assembler? As I recall, you have done
    many routines in ASM for just that reason.



  12. #27
    Dan Barclay Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
    <Steve_Dee@md.prestige.net> wrote:

    >Dan,
    > > the point, it is a fundamental part of the Basic Language. You can
    > > use it or abuse it like any other tool. But, without it the language
    > > isn't Basic.

    >
    >Visual Basic hasn't been "Basic" in the classic sense for a long time. You
    >know that.


    It's been a (fairly) consistent language, with all it's parts.

    >
    >> Did someone appoint you Style Judge? It is *far* easier to read code
    >> if you use GoSub properly. GoSub stopped being more efficient about

    >
    >Well yes they did...but not the "Style Judge" of the world. Sometimes it's
    >hard to get my day job out of my "newsgroup" posts. Part of my job (among
    >other things) for the past 10 years has been to be the "Style Judge/Code
    >Cop, etc." Someone must think it is worthwhile or people would quit
    >recruiting me away from places.
    >
    >I really don't think that Gosub is easier to read, even if used "properly".
    >I also think it's a bad idea to expose new programmers to something that the
    >language dealer (for years) has told us is going away someday.


    Well, the joke's on you. You are wrong. GoSub is a very handy
    construct and is not a bad habit. As I've shown before with
    pseudo-code examples it's a good way to avoid repeating code fragments
    when full-blown procedures are not in order. It's also a good way to
    organize code and separate functional fragments from higher level
    logic. Repeated code fragments are an open invitation to maintenance
    headaches.

    >
    >> VB4 as I recall. Prior to that it was much faster than a Call. In
    >> fact, in the DOS compilers GoSub compiled to an ASM Call/Ret pair.

    >
    >Sure it was...did the speed alone mean it was a good thing? I think
    >not....and it was more than likely a jmp/ret pair. But if you wanted pure
    >speed with jmp/ret, why not DO it in Assembler? As I recall, you have done
    >many routines in ASM for just that reason.


    What the **** are you talking about??? jmp/ret pair? jmp puts
    nothing on the stack! Now *that* could explain some of your problems!
    Is the rest of your "style judge" based background as effective?

    I should do *what* in assembler? You mean wrap some Basic code
    fragments in assembler and call it? If you mean writing tight code in
    ASM, that's exactly what I'd do... but that's not what we're
    discussing here.

    Back to the points: (1) GoSub is a good tool for writing maintainable
    code and (2) in previous versions there was *no* performance penalty
    compared to any other method of procedure call. In fact, on
    performance there was no comparison with a Sub/Function call.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)

  13. #28
    Steve Dee Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    Dan,
    > It's been a (fairly) consistent language, with all it's parts.


    Has it? Look at this:

    Unsupported Keywords
    Visual Basic for Windows omits about 100 keywords that are supported by
    Visual Basic for MS-DOS. Using any of these keywords in the MS-DOS
    application that you convert to Windows results in omitted functionality.
    You must rewrite any code that relies on these keywords:



    ALL INKEY$ SEEKEQ
    BLOAD INP SEEKGE
    BOF INSERT SEEKGT
    BSAVE IOCTL SEG
    CALLS IOCTL$ SETINDEX
    CDECL ISAM SETMEM
    CHAIN KEY SETUEVENT
    CHECKPOINT LIST SIGNAL
    COLOR LOCATE SLEEP
    COM LPOS SOUND
    COMMON LPRINT SSEG
    CREATEINDEX MKC$ SSEGADD
    CSRLIN MKDMBF$ STACK
    CVI MKI$ STICK
    CVC MKL$ STRIG
    CVD MKS$ SWAP
    CVDMBF MKSMBF$ SYSTEM
    CVL OUT TEXTCOMP
    CVS PAINT TRON
    CVSMBF PALETTE TROFF
    DELETEINDEX PCOPY UEVENT
    DELETETABLE PEEK UPDATE
    DRAW PEN VARPTR
    ERDEV PLAY VARPTR$
    ERDEV$ PMAP VARSEG
    EVENT POS VIEW
    FIELD PRESET WAIT
    FILES RUN WINDOW
    FN SADD
    FRE SAVEPOINT
    GETINDEX$ SCREEN
    NOTE: Visual Basic for Windows does not support DEF FN functions.
    Different Coding Mechanisms
    The scoping mechanisms in Visual Basic for MS-DOS are different from those
    in Visual Basic for Windows, as shown by this table:

    Visual Basic MS-DOS construction Visual Basic for Windows equivalent
    COMMON SHARED Public
    DIM SHARED (at module level) Dim (at module level)
    SHARED attribute (procedure level) None. Use module-level variable, which is
    visible to all procedures
    COMMON None. Module-level [ASCII 150] only variables are not useful in
    Visual Basic for Windows

    Visual Basic for MS-DOS applications cannot display forms and graphics at
    the same time. This limitation does not exist in Visual Basic for Windows.
    Code that displays graphics must be completely rewritten for use in Windows.

    > Well, the joke's on you. You are wrong. GoSub is a very handy
    > construct and is not a bad habit. As I've shown before with
    > pseudo-code examples it's a good way to avoid repeating code fragments
    > when full-blown procedures are not in order. It's also a good way to
    > organize code and separate functional fragments from higher level
    > logic. Repeated code fragments are an open invitation to maintenance
    > headaches.


    And I still disagree. You could do the same with different constructs.

    > What the **** are you talking about??? jmp/ret pair? jmp puts
    > nothing on the stack! Now *that* could explain some of your problems!


    So you are trying to say that the "classic" Gosub put something on the
    stack? I simply said that a "Call/Ret" was more likely a jmp/ret....as it
    was in line basic. Or do you not remember that?

    > Is the rest of your "style judge" based background as effective?


    Must be.....I'm doing quite well thank you very much.

    > Back to the points: (1) GoSub is a good tool for writing maintainable
    > code and (2) in previous versions there was *no* performance penalty


    Since when? Look I really don't want to argue with you and have stated that
    someone with a old massive code base such as you have has a problem......I
    feel for you. But I don't think that is a good enough reason to hang on or
    ***** about something that should not be in a modern language.





  14. #29
    Dan Barclay Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    On Tue, 30 Jan 2001 00:19:39 -0500, "Steve Dee"
    <Steve_Dee@md.prestige.net> wrote:

    >Dan,
    >> It's been a (fairly) consistent language, with all it's parts.

    >
    >Has it? Look at this:


    Absolutely. I've stated a number of times that there are 3 occasions
    where MS has broken MS Basic. Each time with more gusto, this time
    with devastation.

    VB1 resulted in loss of a number of keywords. *most* but not all were
    a result of the environment change. The gratuitous changes were
    things like FIELD, CVx() and friends, MKx$() and friends and several
    others.

    You will also note that VBDOS came out *AFTER* VB for Windows. Many
    of the keywords listed below are from the lame ISAM library that was
    an add-on library starting with PDS. Those, were linked library
    functions and not a part of the core Basic language.

    What's more, as I've said *many* times before, I have no beef with
    changes to the language that are caused by a change in the
    environment. PEEK/POKE/FRE()/ and user I/O are environment related.

    I mentioned there were two major hits. VB1 was one, VB4 was the
    second. In that change they added Unicode 'support'. In adding this
    new type of data they did *not* add a new data type. Instead they
    hijacked the $tring data type. In prior versions the *only*
    documented way to handle binary data was with $trings. With VB4/32
    $trings were documented to corrupt binary data. Millions of lines of
    code broken in one fell swoop.

    >> Well, the joke's on you. You are wrong. GoSub is a very handy
    >> construct and is not a bad habit. As I've shown before with
    >> pseudo-code examples it's a good way to avoid repeating code fragments
    >> when full-blown procedures are not in order. It's also a good way to
    >> organize code and separate functional fragments from higher level
    >> logic. Repeated code fragments are an open invitation to maintenance
    >> headaches.

    >
    >And I still disagree. You could do the same with different constructs.


    You can do a lot of things with different constructs. You don't need
    "If" anymore either. Anything you can do with "If" you can do with
    "Select Case". Do you really think you have justification for
    eliminating "If"?

    >
    >> What the **** are you talking about??? jmp/ret pair? jmp puts
    >> nothing on the stack! Now *that* could explain some of your problems!

    >
    >So you are trying to say that the "classic" Gosub put something on the
    >stack? I simply said that a "Call/Ret" was more likely a jmp/ret....as it
    >was in line basic. Or do you not remember that?


    Yes, "Classic" GoSub put something on the stack.

    ====The source:====
    dim i%
    gosub ThisSub
    end
    ThisSub:
    i%=i%+1
    return
    ====compiles to:=====

    PAGE 1

    30 Jan 01

    13:10:29
    Offset Data Source Line Microsoft (R) Visual Basic (TM) for
    MS-DOS (R)

    0030 ** I00002: call I00003
    0033 ** call B$CEND
    0038 ** I00003: inc i%
    003C ** ret

    =======================
    Please note the 'call I00003' to offset 0038, with the ret following.

    You'll also note that the i%=i%+1 compiles to a single inc.

    >> Is the rest of your "style judge" based background as effective?

    >
    >Must be.....I'm doing quite well thank you very much.


    We get it here for free... and I must say it's worth every cent. You
    don't make something better by removing features.

    >> Back to the points: (1) GoSub is a good tool for writing maintainable
    >> code and (2) in previous versions there was *no* performance penalty

    >
    >Since when? Look I really don't want to argue with you and have stated that
    >someone with a old massive code base such as you have has a problem......I
    >feel for you. But I don't think that is a good enough reason to hang on or
    >***** about something that should not be in a modern language.


    LOL!

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)

  15. #30
    Mike Mitchell Guest

    Re: Editorial by Russell Jones/Attack on Gosub

    On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
    <Steve_Dee@md.prestige.net> wrote:

    >Sure it was...did the speed alone mean it was a good thing? I think
    >not....and it was more than likely a jmp/ret pair. But if you wanted pure
    >speed with jmp/ret, why not DO it in Assembler? As I recall, you have done
    >many routines in ASM for just that reason.
    >


    That's right! Why simplify when you can obfuscate? Of COURSE most
    anything could have been done in assembly language, but you're
    incriminating the humble GoSub with far more than it deserves. It
    wasn't used for speed, it was used for structure - in the days when
    precious few other constructs were available. Why can't you just
    accept that GoSub has been around for years, does a perfectly adequate
    job in the right hands, has largely been superseded by functions, but
    still didn't deserve to be summarily executed for being ancient. No
    one is *forcing* you or anyone else to use it!

    MM


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