Re: basic Q: Only one way to make vars live outside of the scope of a function without globals?

Great answer, Joe, thank you so very much for your thoughtful reply.

Could I ask one other favor of you? You mention a system/convention of
prefixing that describes the scope of the variable and other useful
attributes to know. Can you show a sample of this convention, or maybe
recommend a book that describes the convention that you use? I'm very
interested.

I've been on a six-month tear of reading through the best comp sci/comp
engineering literature I can find, and it's pretty cool to see all of the
tips, tricks and philosophies I've digested translated into markedly better
code. Your system sounds like something worth internalizing.

-KF


"Joe Earnest" <jearnest3-SPAM@xxxxxxxxxxxxx> wrote in message
news:uKp1D%23eTFHA.3344@xxxxxxxxxxxxxxxxxxxxxxx
> Hi,
>
> <kenfine@xxxxxxxxxxxxxxxx> wrote in message
> news:eGg2QRdTFHA.616@xxxxxxxxxxxxxxxxxxxxxxx
> > This is a basic question about the design and intent of functions in
> > programming languages like VBscript.
> >
> > I know how to write VBScript functions and to pass parameter variables
in
> > and out of them.
> >
> > As I've become a smarter programmer, I'm inclined to translate the lousy
> > code that I wrote when I didn't know what was doing into more
granularized
> > and encapsulated functions and/or classes.
> >
> > I was revisiting some VBScript browser detection code that looked
> > something
> > like this:
> >
> > ' check something
> > ' set a variable based on result of check
> > ' check something else
> > ' set a different variable based on result of check
> > ' check something else
> > ' set a different variable based on result of check
> >
> > The code sets about a dozen different variables of interest. The code
was
> > not organized as a function. It's certainly easy enough to make it a sub
> > or
> > function and to call it, but the variables that are set internally in
the
> > function don't live outside of the scope of the function.
> >
> > I want someone to confirm that the "correct" way/only way to make many
> > variables survive outside of the function is to return an object (e.g.
an
> > array) of values upon the function's completion.
> >
> > The function could write global vars, but that isn't good practice.
> >
> > Am I correct in this, or is there another way that I'm missing?
> >
> > Thank you,
> > Ken Fine
>
> For my two cents worth ...
>
> You missed a thread a couple of weeks ago where Al Dunbar (one of the MVPs
> here) and I had a lengthy "discussion" over a slightly more complex
version
> of your question.
>
> Given the straightforward nature of your question, I believe that the
answer
> is clearly "no," and I believe that most VBS scripters would agree, though
> perhaps in different ways.
>
> An array return (in scripting, "object" usually refers to a COM object
> instance and a specific data subtype) is great for similar multiple items.
> But it is the most obscure return, since you don't have the benefit of the
> variable name to provide quick identification. And at times you may want
to
> return quite different values -- both strings and object instances, or
> different types of references -- from a single function.
>
> VBS (unlike JS and some other languages) maintains the ByRef/ByVal
argument
> distinction, and defaults to ByRef. ByRef arguments provide for returns
> directly to the calling script, without having to use global variables to
> achieve the return. Indeed, there is no functional difference between the
> transitory function-name return and a ByRef argument variable return.
ByRef
> arguments have been the traditional method in BASIC programming, since
early
> DOS days, to get multiple return items from a subprocedure.
>
> mainNumRtn= myFunction(useValue1, useValue2, rtnObjVar, rtnStrVar)
>
> WMI functions are replete with return arguments -- indeed the WMI registry
> access system only works that way.
>
> The "trick", if you will, in using ByRef argument returns is either to
> document the function or to use a scope-oriented and functional variable
> prefixing system (instead of a simple variable-type system, which may not
be
> too useful in a pure variant language such as VBS). I strongly prefer
real
> prefixing. I can tell by looking at the first character of the argument
> variable name that I assign whether it's passed ByVal or ByRef, and if
> ByRef, whether its preserved, destroyed, coerced to the data type and
range
> required by the function, requires precise assignment, or set and
returned.
> The VBS option to use ByRef arguments is very efficient. But to take
> advantage of it, you must be willing to coerce or destroy some argument
> values, as well as reset some for return. This requires comment or a
> meaningful prefixing system, both to preserve your sanity and for reuse of
> the function in future scripts.
>
> A ByRef return argument for a function can be analogized to a property
> return for a method function. If your writing classes, you should
consider
> associated property returns. Since most I now write my fundamental
> functions as WSC VBS, I again use global variables for multiple return
> values, though these are declared in the parent XML script as properties
and
> returned to the calling script as properties. As you note, it is
generally
> better not to mix scope and use global variables for multiple return
values,
> in straight script, since it makes it hard to reuse the functions that you
> write.
>
> Regards,
> Joe Earnest
>
>


.

Relevant Pages