sub or function

[Roland Hall]

I'm tired of getting beat up on this issue so I thought I'd ask what you
some of you think.

I know the basic difference between a subroutine and a function is a
subroutine performs a task and a function performs a task and returns a
value. The Call keyword is required when using parens with subs with more
than 1 parameters. Parens around values passed are ByVal vs ByRef and is a
waste of processing if passed ByRef for no reason.

I am told there is no reason to ever use a subroutine as a function can be
used even if it doesn't return a value. While this appears to be true, is
there any reason why it's ever a bad idea to use a function, instead of a
subroutine, that doesn't return a value? Are there memory, performance,
etc. issues?

TIA...

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Curt_C [MVP]]

Roland Hall wrote:

I'm tired of getting beat up on this issue so I thought I'd ask what you
some of you think.

I know the basic difference between a subroutine and a function is a
subroutine performs a task and a function performs a task and returns a
value. The Call keyword is required when using parens with subs with more
than 1 parameters. Parens around values passed are ByVal vs ByRef and is a
waste of processing if passed ByRef for no reason.

I am told there is no reason to ever use a subroutine as a function can be
used even if it doesn't return a value. While this appears to be true, is
there any reason why it's ever a bad idea to use a function, instead of a
subroutine, that doesn't return a value? Are there memory, performance,
etc. issues?

TIA...

There may be some perf loss but these days I doubt you would notice...
Best answer is, almost always, do what you feel comfortable with as long
as it does what you need it to.....

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

[Bob Barrows [MVP]]

Roland Hall wrote:

I'm tired of getting beat up on this issue so I thought I'd ask what
you some of you think.
Somebody's beating you up about this ... ??
<snip> I am told there is no reason to ever use a subroutine as a function
can be used even if it doesn't return a value. While this appears to
be true, is there any reason why it's ever a bad idea to use a
function, instead of a subroutine, that doesn't return a value? Are
there memory, performance, etc. issues?

As far as performance is concerned, I think Eric says it best:
http://blogs.msdn.com/ericlippert/ar.../17/53237.aspx

The whole "function vs sub" controversy seems to have devolved into a
religious debate, much like the top-posters vs. inline posters...

Back in the day of VB3, using a sub instead of a function might have made a
difference as far as memory or performance is concerned. Nowadays, it's
really just personal preference.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Roland Hall]

"Bob Barrows [MVP]" wrote in message
news:OS****************@TK2MSFTNGP15.phx.gbl...
: Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what
: > you some of you think.
:
: Somebody's beating you up about this ... ??

Two people actually because of what I said to someone else regarding their
style of coding

Call somefunction(param1, param2)

: > I am told there is no reason to ever use a subroutine as a function
: > can be used even if it doesn't return a value. While this appears to
: > be true, is there any reason why it's ever a bad idea to use a
: > function, instead of a subroutine, that doesn't return a value? Are
: > there memory, performance, etc. issues?
: >
:
: As far as performance is concerned, I think Eric says it best:
: http://blogs.msdn.com/ericlippert/ar.../17/53237.aspx
:
: The whole "function vs sub" controversy seems to have devolved into a
: religious debate, much like the top-posters vs. inline posters...

Is vbs now to be thought of as jscript where everything is a function?

: Back in the day of VB3, using a sub instead of a function might have made
a
: difference as far as memory or performance is concerned. Nowadays, it's
: really just personal preference.

Are you stating there is not difference other than one can return a value?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"Curt_C [MVP]" <software_at_darkfalz.com> wrote in message
news:eM**************@TK2MSFTNGP14.phx.gbl...
: Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what you
: > some of you think.
: >
: > I know the basic difference between a subroutine and a function is a
: > subroutine performs a task and a function performs a task and returns a
: > value. The Call keyword is required when using parens with subs with
more
: > than 1 parameters. Parens around values passed are ByVal vs ByRef and
is a
: > waste of processing if passed ByRef for no reason.
: >
: > I am told there is no reason to ever use a subroutine as a function can
be
: > used even if it doesn't return a value. While this appears to be true,
is
: > there any reason why it's ever a bad idea to use a function, instead of
a
: > subroutine, that doesn't return a value? Are there memory, performance,
: > etc. issues?
: >
: > TIA...
: >
:
: There may be some perf loss but these days I doubt you would notice...

Would that unnoticeable difference be relevant if there were hundreds or
thousands of users?

: Best answer is, almost always, do what you feel comfortable with as long
: as it does what you need it to.....

I try but the law keeps responding with, "She must be at least 18!"

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Bob Barrows [MVP]]

Roland Hall wrote:

"Bob Barrows [MVP]" wrote in message
news:OS****************@TK2MSFTNGP15.phx.gbl...

Roland Hall wrote:

The whole "function vs sub" controversy seems to have devolved into a
religious debate, much like the top-posters vs. inline posters...
Is vbs now to be thought of as jscript where everything is a function?

I don't think I said that.

It CAN be thought of that way. It doesn't have to be. I still use subs
extensively, I'm accustomed to them - it's mainly a matter of style.

Back in the day of VB3, using a sub instead of a function might have
made a difference as far as memory or performance is concerned.
Nowadays, it's really just personal preference.

Are you stating there is not difference other than one can return a
value?

Yeah, pretty much. The slight overhead involved in creating the memory space
to contain the returned value (in the case of functions) is avoided when
using a sub. And at some time in the past, perhaps that difference may have
noticeable in VB. But not with today's machines. And definitely not with
vbscript which has many more performance issues than using subs vs
functions.

There is one advantage to using functions: with a function, you can return a
boolean to indicate the success/failure of the procedure. With a sub, you
either have to raise an error or use an extra ByRef argument to let the
calling procedure know about the sub's outcome. Raising errors definitely
definitely has a performance impact: much more than using a function instead
of a sub.

Also, using functions exclusively will make the transition to jscript or C#
a little easier (not much, but a little).

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[CJM]

The only thing I can add to Bob's post is that one advantage of using both
Subs & Functions is that there is a little greater clarity. You can expect a
return from a Function but not from a Sub, so it's arguably a little easier
to debug - you know what to expect. Ok, it's not the greatest advantage, but
it can help!

CJM

[Roland Hall]

"CJM" wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
: The only thing I can add to Bob's post is that one advantage of using both
: Subs & Functions is that there is a little greater clarity. You can expect
a
: return from a Function but not from a Sub, so it's arguably a little
easier
: to debug - you know what to expect. Ok, it's not the greatest advantage,
but
: it can help!

Well, I thought there was a memory issue although negligible, it increases
with each concurrent user. I see no reason to waste memory just because I
can. And you stated it as I use them to know a sub is not going to return a
value and a function will return one so it IS easier to read and debug, at
least for me.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"Bob Barrows [MVP]" wrote in message
news:Ol****************@TK2MSFTNGP15.phx.gbl...
: Roland Hall wrote:
: > "Bob Barrows [MVP]" wrote in message
: > news:OS****************@TK2MSFTNGP15.phx.gbl...
: >> Roland Hall wrote:
: >>
: >> The whole "function vs sub" controversy seems to have devolved into a
: >> religious debate, much like the top-posters vs. inline posters...
: >
: > Is vbs now to be thought of as jscript where everything is a function?
:
: I don't think I said that.

Ok, but if your nose starts to grow...

: It CAN be thought of that way. It doesn't have to be. I still use subs
: extensively, I'm accustomed to them - it's mainly a matter of style.

Outside of mainly...?

: >> Back in the day of VB3, using a sub instead of a function might have
: >> made a difference as far as memory or performance is concerned.
: >> Nowadays, it's really just personal preference.

See the first question.

: > Are you stating there is not difference other than one can return a
: > value?
:
: Yeah, pretty much. The slight overhead involved in creating the memory
space
: to contain the returned value (in the case of functions) is avoided when
: using a sub. And at some time in the past, perhaps that difference may
have
: noticeable in VB. But not with today's machines. And definitely not with
: vbscript which has many more performance issues than using subs vs
: functions.

So, this is still no longer an issue in VB either?

: There is one advantage to using functions: with a function, you can return
a
: boolean to indicate the success/failure of the procedure. With a sub, you
: either have to raise an error or use an extra ByRef argument to let the
: calling procedure know about the sub's outcome. Raising errors definitely
: definitely has a performance impact: much more than using a function
instead
: of a sub.
:
: Also, using functions exclusively will make the transition to jscript or
C#
: a little easier (not much, but a little).

Transition to jscript? Do you know something? Is everything VB related
going away?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Bob Barrows [MVP]]

Roland Hall wrote:

"Bob Barrows [MVP]" wrote in message
news:Ol****************@TK2MSFTNGP15.phx.gbl...

Roland Hall wrote:

"Bob Barrows [MVP]" wrote in message
news:OS****************@TK2MSFTNGP15.phx.gbl...
Roland Hall wrote:

The whole "function vs sub" controversy seems to have devolved
into a religious debate, much like the top-posters vs. inline
posters...

Is vbs now to be thought of as jscript where everything is a
function?
I don't think I said that.

Ok, but if your nose starts to grow...

Why?

It CAN be thought of that way. It doesn't have to be. I still use
subs extensively, I'm accustomed to them - it's mainly a matter of
style.
Outside of mainly...?

Huh?

Back in the day of VB3, using a sub instead of a function might
have made a difference as far as memory or performance is
concerned. Nowadays, it's really just personal preference.
See the first question.
Why? How can this be translated into "Is vbs now to be thought of as jscript
where everything is a function?"
Maybe I'm misinterpreting that question ... the phrase "to be thought of"
has overtones of "must be thought of". Did you mean it that way? Or did you
mean it more like "can vbs be thought of ... "?
Are you stating there is not difference other than one can return a
value?
Yeah, pretty much. The slight overhead involved in creating the
memory space to contain the returned value (in the case of
functions) is avoided when using a sub. And at some time in the
past, perhaps that difference may have noticeable in VB. But not
with today's machines. And definitely not with vbscript which has
many more performance issues than using subs vs functions.

So, this is still no longer an issue in VB either?

Since VB is compiled, then yes, it may be more of an issue in VB than in
vbscript. However, there are likely to be many more things to worry about
than this, even in VB. It's a little harder to write an application without
subs in VB because all the generated event handlers are created as subs.

There is one advantage to using functions: with a function, you can
return a boolean to indicate the success/failure of the procedure.
With a sub, you either have to raise an error or use an extra ByRef
argument to let the calling procedure know about the sub's outcome.
Raising errors definitely definitely has a performance impact: much
more than using a function instead of a sub.

Also, using functions exclusively will make the transition to
jscript or C# a little easier (not much, but a little).

Transition to jscript? Do you know something? Is everything VB
related going away?

Nope, you've read a little too much into my statement. I should have said:
"IF you are going to learn another language such as jscript, C#, etc., then
the transition will be slightly easier ... "

Bob

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[!TG]

Roland Hall wrote:

I'm tired of getting beat up on this issue so I thought I'd ask what you
some of you think.

I know the basic difference between a subroutine and a function is a
subroutine performs a task and a function performs a task and returns a
value. The Call keyword is required when using parens with subs with more
than 1 parameters. Parens around values passed are ByVal vs ByRef and is a
waste of processing if passed ByRef for no reason.

I am told there is no reason to ever use a subroutine as a function can be
used even if it doesn't return a value. While this appears to be true, is
there any reason why it's ever a bad idea to use a function, instead of a
subroutine, that doesn't return a value? Are there memory, performance,
etc. issues?

TIA...

Subs will change values of preexisting variables if you use the same
generic variables by habit.
Depending on the purpose, this can be an advantage or trouble.

I personally use Subs for mostly simple display tasks and functions for
more complicated work.

[Roland Hall]

"Bob Barrows [MVP]" wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
: Roland Hall wrote:
: > "Bob Barrows [MVP]" wrote in message
: > news:Ol****************@TK2MSFTNGP15.phx.gbl...
: >> Roland Hall wrote:
: >>> "Bob Barrows [MVP]" wrote in message
: >>> news:OS****************@TK2MSFTNGP15.phx.gbl...
: >>>> Roland Hall wrote:
: >>>>
: >>>> The whole "function vs sub" controversy seems to have devolved
: >>>> into a religious debate, much like the top-posters vs. inline
: >>>> posters...
: >>>
: >>> Is vbs now to be thought of as jscript where everything is a
: >>> function?
: >>
: >> I don't think I said that.
: >
: > Ok, but if your nose starts to grow...
:
: Why?

I said, IF.

: >> It CAN be thought of that way. It doesn't have to be. I still use
: >> subs extensively, I'm accustomed to them - it's mainly a matter of
: >> style.
: >
: > Outside of mainly...?
:
: Huh?

If it's mainly a matter of style, what else matters?

: >>>> Back in the day of VB3, using a sub instead of a function might
: >>>> have made a difference as far as memory or performance is
: >>>> concerned. Nowadays, it's really just personal preference.
: >
: > See the first question.
:
: Why? How can this be translated into "Is vbs now to be thought of as
jscript
: where everything is a function?"
: Maybe I'm misinterpreting that question ... the phrase "to be thought of"
: has overtones of "must be thought of". Did you mean it that way? Or did
you
: mean it more like "can vbs be thought of ... "?

'can' could probably work but probably my meaning was 'should'
Should I just use functions and eliminate the use of subs in vbscript?
(remove the arguments for readability and negligible memory loss)

: >>> Are you stating there is not difference other than one can return a
: >>> value?
: >>
: >> Yeah, pretty much. The slight overhead involved in creating the
: >> memory space to contain the returned value (in the case of
: >> functions) is avoided when using a sub. And at some time in the
: >> past, perhaps that difference may have noticeable in VB. But not
: >> with today's machines. And definitely not with vbscript which has
: >> many more performance issues than using subs vs functions.
: >
: > So, this is still no longer an issue in VB either?
:
: Since VB is compiled, then yes, it may be more of an issue in VB than in
: vbscript. However, there are likely to be many more things to worry about
: than this, even in VB. It's a little harder to write an application
without
: subs in VB because all the generated event handlers are created as subs.

This is the type of answer I was looking for. I guess you're saying
vbscript doesn't have requirements like this.

: > Transition to jscript? Do you know something? Is everything VB
: > related going away?
: >
: Nope, you've read a little too much into my statement. I should have said:
: "IF you are going to learn another language such as jscript, C#, etc.,
then
: the transition will be slightly easier ... "

Nah, I was just yanking your chain on this question. Wonder how many MSFT
emps read it and said, "Ya', what has he heard?" or "Aw crap! Cats outta'
the bag."

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"!TG" wrote in message news:%2******************@TK2MSFTNGP14.phx.gbl...
: Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what you
: > some of you think.
: >
: > I know the basic difference between a subroutine and a function is a
: > subroutine performs a task and a function performs a task and returns a
: > value. The Call keyword is required when using parens with subs with
more
: > than 1 parameters. Parens around values passed are ByVal vs ByRef and
is a
: > waste of processing if passed ByRef for no reason.
: >
: > I am told there is no reason to ever use a subroutine as a function can
be
: > used even if it doesn't return a value. While this appears to be true,
is
: > there any reason why it's ever a bad idea to use a function, instead of
a
: > subroutine, that doesn't return a value? Are there memory, performance,
: > etc. issues?
: >
: > TIA...
: >
:
: Subs will change values of preexisting variables if you use the same
: generic variables by habit.
: Depending on the purpose, this can be an advantage or trouble.

Are you saying a passed variable to a sub, if the value changes will change
the value of a global variable? Isn't that only true if it's passed ByRef?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[CJM]

"Roland Hall" <nobody@nowhere> wrote in message
news:OZ**************@TK2MSFTNGP15.phx.gbl...

Are you saying a passed variable to a sub, if the value changes will
change
the value of a global variable? Isn't that only true if it's passed
ByRef?

From MSDN:
http://msdn.microsoft.com/library/de...l/vsstmsub.asp

"Variables used in Sub procedures fall into two categories: those that are
explicitly declared within the procedure and those that are not. Variables
that are explicitly declared in a procedure (using Dim or the equivalent)
are always local to the procedure. Variables that are used but not
explicitly declared in a procedure are also local, unless they are
explicitly declared at some higher level outside the procedure.

Caution A procedure can use a variable that is not explicitly declared in
the procedure, but a naming conflict can occur if anything you have defined
at the script level has the same name. If your procedure refers to an
undeclared variable that has the same name as another procedure, constant or
variable, it is assumed that your procedure is referring to that
script-level name. To avoid this kind of conflict, use an Option Explicit
statement to force explicit declaration of variables."

I'm not sure this quote entirely answers the question, but it was
interesting anyway. But as I see it, if you pass a Global variable ByVal it
is treated as a local variable; if you pass it ByRef, any changes are
reflected in the calling procedure - which means that if the variable had
Global scope it would be changed throughout the application. Which I'm
guessing was you original understanding?

However, if you were talking about a Global variable, there would be no
reason to pass it as a parameter because it already accessible because it
is...er.. Global!

I hope this hasn't muddied the water any further!

Chris

[Bob Lehmann]

>> Isn't that only true if it's passed ByRef?
The default is ByRef in VBScript. So, unless you you explicitly pass it
ByVal, it will be changed.

Bob Lehmann

"Roland Hall" <nobody@nowhere> wrote in message
news:OZ**************@TK2MSFTNGP15.phx.gbl...

"!TG" wrote in message news:%2******************@TK2MSFTNGP14.phx.gbl...
: Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what you : > some of you think.
: >
: > I know the basic difference between a subroutine and a function is a
: > subroutine performs a task and a function performs a task and returns a : > value. The Call keyword is required when using parens with subs with
more
: > than 1 parameters. Parens around values passed are ByVal vs ByRef and
is a
: > waste of processing if passed ByRef for no reason.
: >
: > I am told there is no reason to ever use a subroutine as a function can be
: > used even if it doesn't return a value. While this appears to be true, is
: > there any reason why it's ever a bad idea to use a function, instead of a
: > subroutine, that doesn't return a value? Are there memory, performance, : > etc. issues?
: >
: > TIA...
: >
:
: Subs will change values of preexisting variables if you use the same
: generic variables by habit.
: Depending on the purpose, this can be an advantage or trouble.

Are you saying a passed variable to a sub, if the value changes will change the value of a global variable? Isn't that only true if it's passed ByRef?
--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"CJM" <cj*******@newsgroup.nospam> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
:
: "Roland Hall" <nobody@nowhere> wrote in message
: news:OZ**************@TK2MSFTNGP15.phx.gbl...
: >
: > Are you saying a passed variable to a sub, if the value changes will
: > change
: > the value of a global variable? Isn't that only true if it's passed
: > ByRef?
:
: However, if you were talking about a Global variable, there would be no
: reason to pass it as a parameter because it already accessible because it
: is...er.. Global!
:
: I hope this hasn't muddied the water any further!

No problem.

What if it is passed from another sub/function?

function myincfunc(x)
myincfunc= x + 1
end function

sub tomorrow(x)
dim thisday, nextday
thisday = x
nextday = myincfunc(thisday)
Response.Write "Tomorrow's secret number is: " & nextday
end sub

dim x
x = 4
tomorrow x

x is global
sub x is byRef, assigned byVal to thisday, passed byRef to func x,
incremented and returned

Did any initial variables change?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"Bob Lehmann" wrote in message news:ef**************@TK2MSFTNGP09.phx.gbl...
: >> Isn't that only true if it's passed ByRef?
: The default is ByRef in VBScript. So, unless you you explicitly pass it
: ByVal, it will be changed.

I know it [global variable] changes because I've been caught with my pants
down on this issue before and had to use ByVal to get out of it but it was a
global variable I was passing, which was not required. A local variable
will also change if passed byRef to another sub/function?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[CJM]

Problem spotted - I'm an idiot.

Of course, when we run test1() it is updating the variable y.

Modified code:

<%@ Language="VBScript" %>
<%

Option Explicit

Dim x

function test1(x)
x = x + 10
test1 = x
End function

function test2()
x = x + 1
test2 = x
end function

sub test0()
dim y, z

y = x

z = test1(y)

response.Write "Test1.1: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"

z = test1(y)

response.Write "Test1.2: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"

z = test2()

response.Write "Test2.1: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"

z = test2()

response.Write "Test2.2: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"
end sub

x = 0

response.Write "Pass1: <br>"
test0()

response.Write "<br>Pass2: <br>"
test0()
%>

[Chris Hohmann]

"Roland Hall" <nobody@nowhere> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...

A local variable
will also change if passed byRef to another sub/function?

Yes.

<%
Option Explicit
Function Foo(parameter_by_ref)
Dim return_value, local_variable
local_variable = parameter_by_ref
return_value = Bar(local_variable)
Foo = local_variable
End Function

Function Bar(parameter_by_ref)
parameter_by_ref = parameter_by_ref + 1
Bar = "Hello World"
End Function

Response.Write Foo(4)
%>

[Chris Hohmann]

"CJM" <cj*******@newsgroup.nospam> wrote in message
news:uh**************@TK2MSFTNGP12.phx.gbl...

"Roland Hall" <nobody@nowhere> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

What if it is passed from another sub/function?

function myincfunc(x)
myincfunc= x + 1
end function

sub tomorrow(x)
dim thisday, nextday
thisday = x
nextday = myincfunc(thisday)
Response.Write "Tomorrow's secret number is: " & nextday
end sub

dim x
x = 4
tomorrow x

x is global
sub x is byRef, assigned byVal to thisday, passed byRef to func x,
incremented and returned

Did any initial variables change?

AFAIK...

The x in myincfunc is local to the function - it is not the same as the
global variable x. So in this instance the global variable x does not
change.

If we change the function to:

function myincfunc()
myincfunc= x + 1
end function

...so there is no incoming parameter, x the global variable x would be
incremented each time the function is called.

[10 minute interlude...]

Right! I've created a test page. It kind of proved what I was saying with
one exception which I dont understand!

Here's the code:

<%@ Language="VBScript" %>
<%

Option Explicit

Dim x

function test1(x)
x = x + 10
test1 = x
End function

function test2()
x = x + 1
test2 = x
end function

sub test0()
dim y, z

y = x

z = test1(y)

response.Write "Test1.1: " & z & "<br>"
response.Write "x = " & x & "<br>"

z = test1(y)

response.Write "Test1.2: " & z & "<br>"
response.Write "x = " & x & "<br>"

z = test2()

response.Write "Test2.1: " & z & "<br>"
response.Write "x = " & x & "<br>"

z = test2()

response.Write "Test2.2: " & z & "<br>"
response.Write "x = " & x & "<br>"
end sub

x = 0

response.Write "Pass1: <br>"
test0()

response.Write "<br>Pass2: <br>"
test0()
%>

And here are my results:

Pass1:
Test1.1: 10
x = 0
Test1.2: 20
x = 0
Test2.1: 1
x = 1
Test2.2: 2
x = 2

Pass2:
Test1.1: 12
x = 2
Test1.2: 22
x = 2
Test2.1: 3
x = 3
Test2.2: 4
x = 4

It all behaves as I would expect, except for test 1.2. In these cases, I
would expect the returned result to be the same as Test1.1 UNLESS the
global variable x is indeed being updated. However, we can see from the
next line that x only appears to be updated by the test2 function.

3 Possibilities:
- A Bug: possible but doubtful
- A cock-up in my code: usually very likely
- Correct behaviour though for unknown reasons: is this the case?
Any thoughts?

Chris

Everything is behaving as it should. In test 1.1 the a _reference_ to the
local y variable in test0 is being passed to the test1 function. Since it's
a reference, the local y variable in test0 gets incremented to 10. When the
local y variable is pass by _reference_ to the test1 function for a second
time in test 1.2, it is again incremented by 10, resulting in a value of 20.
Basically, all parameters, regardless of scope, are passed by reference
unless explicitly told otherwise.

[Chris Hohmann]

"Chris Hohmann" <no****@thankyou.com> wrote in message
news:OV**************@TK2MSFTNGP14.phx.gbl...

In test 1.1 the a _reference_ to the local y variable in test0 is being
passed to the test1 function.

That should read:

In test 1.1 a _reference_ to the ...

[Roland Hall]

"CJM" wrote in message news:Oo**************@TK2MSFTNGP10.phx.gbl...
: Problem spotted - I'm an idiot.

Hardly...

: Of course, when we run test1() it is updating the variable y.
:
: Modified code:
:
: <%@ Language="VBScript" %>
: <%
:
: Option Explicit
:
: Dim x
:
: function test1(x)
: x = x + 10
: test1 = x
: End function
:
: function test2()
: x = x + 1
: test2 = x
: end function
:
: sub test0()
: dim y, z
:
: y = x
:
: z = test1(y)
:
: response.Write "Test1.1: " & z & "<br>"
: response.Write "x = " & x & "<br>"
: response.Write "y = " & y & "<br>"
:
: z = test1(y)
:
: response.Write "Test1.2: " & z & "<br>"
: response.Write "x = " & x & "<br>"
: response.Write "y = " & y & "<br>"
:
: z = test2()
:
: response.Write "Test2.1: " & z & "<br>"
: response.Write "x = " & x & "<br>"
: response.Write "y = " & y & "<br>"
:
: z = test2()
:
: response.Write "Test2.2: " & z & "<br>"
: response.Write "x = " & x & "<br>"
: response.Write "y = " & y & "<br>"
: end sub
:
: x = 0
:
: response.Write "Pass1: <br>"
: test0()
:
: response.Write "<br>Pass2: <br>"
: test0()
: %>

Great example. Very helpful. Thanks.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"Chris Hohmann" wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...
: "Roland Hall" <nobody@nowhere> wrote in message
: news:uc**************@TK2MSFTNGP10.phx.gbl...
: > A local variable
: > will also change if passed byRef to another sub/function?
:
: Yes.
:
: <%
: Option Explicit
: Function Foo(parameter_by_ref)
: Dim return_value, local_variable
: local_variable = parameter_by_ref
: return_value = Bar(local_variable)
: Foo = local_variable
: End Function
:
: Function Bar(parameter_by_ref)
: parameter_by_ref = parameter_by_ref + 1
: Bar = "Hello World"
: End Function
:
: Response.Write Foo(4)
: %>

Also helpful... thanks.

This was very interesting to see:

Option Explicit
Function Foo(parameter_by_ref)
Dim return_value, local_variable
local_variable = parameter_by_ref
Bar(local_variable)
Foo = local_variable
End Function

sub Bar(parameter_by_ref)
parameter_by_ref = parameter_by_ref + 1
End sub

wscript.echo Foo(4)

Result: 4

Option Explicit
Function Foo(parameter_by_ref)
Dim return_value, local_variable
local_variable = parameter_by_ref
Bar local_variable
Foo = local_variable
End Function

sub Bar(parameter_by_ref)
parameter_by_ref = parameter_by_ref + 1
End sub

wscript.echo Foo(4)

Result: 5

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Chris Hohmann]

"Roland Hall" <nobody@nowhere> wrote in message
news:eE**************@tk2msftngp13.phx.gbl...

"Chris Hohmann" wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...
: "Roland Hall" <nobody@nowhere> wrote in message
: news:uc**************@TK2MSFTNGP10.phx.gbl...
: > A local variable
: > will also change if passed byRef to another sub/function?
:
: Yes.
:
: <%
: Option Explicit
: Function Foo(parameter_by_ref)
: Dim return_value, local_variable
: local_variable = parameter_by_ref
: return_value = Bar(local_variable)
: Foo = local_variable
: End Function
:
: Function Bar(parameter_by_ref)
: parameter_by_ref = parameter_by_ref + 1
: Bar = "Hello World"
: End Function
:
: Response.Write Foo(4)
: %>

Also helpful... thanks.

This was very interesting to see:

Option Explicit
Function Foo(parameter_by_ref)
Dim return_value, local_variable
local_variable = parameter_by_ref
Bar(local_variable)
Foo = local_variable
End Function

sub Bar(parameter_by_ref)
parameter_by_ref = parameter_by_ref + 1
End sub

wscript.echo Foo(4)

Result: 4

Option Explicit
Function Foo(parameter_by_ref)
Dim return_value, local_variable
local_variable = parameter_by_ref
Bar local_variable
Foo = local_variable
End Function

sub Bar(parameter_by_ref)
parameter_by_ref = parameter_by_ref + 1
End sub

wscript.echo Foo(4)

Result: 5

In your first example, this line:

Bar(local_variable)

is interpreted by the parser as passing the expression "(local_variable)" to
the Bar procedure. The parenthesis in this case causes the parser to
interpret the argument being passed to the Bar procedure as a complex
expression instead of a simple variable reference. As such, what's being
passed in this case is a reference to the implicit/pseudo variable used to
hold the result of evaluating the "(local_variable)" expression. It would be
akin to this call:

Bar local_variable + 1

Or this one:

Bar (local_variable + 1)

Or this one:

Bar 22/7

You get the idea.

[CJM]

"Roland Hall" <nobody@nowhere> wrote in message

Great example. Very helpful. Thanks.

No probs... In return, would you please do the Despatch Planning report that
I was supposed to be doing while I did this?

Cheers

Chris

[Roland Hall]

"CJM" <cj*******@yahoo.co.uk> wrote in message
news:3l*************@individual.net...
:
: "Roland Hall" <nobody@nowhere> wrote in message
: >
: > Great example. Very helpful. Thanks.
:
: No probs... In return, would you please do the Despatch Planning report
that
: I was supposed to be doing while I did this?

Piece of cake. When would you like it completed?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

[Roland Hall]

"Chris Hohmann" wrote in message
news:uM**************@TK2MSFTNGP14.phx.gbl...
: "Roland Hall" <nobody@nowhere> wrote in message
: news:eE**************@tk2msftngp13.phx.gbl...
: > "Chris Hohmann" wrote in message
: > news:e2**************@TK2MSFTNGP14.phx.gbl...
: > : "Roland Hall" <nobody@nowhere> wrote in message
: > : news:uc**************@TK2MSFTNGP10.phx.gbl...
: > : > A local variable
: > : > will also change if passed byRef to another sub/function?
: > :
: > : Yes.
: > :
: > : <%
: > : Option Explicit
: > : Function Foo(parameter_by_ref)
: > : Dim return_value, local_variable
: > : local_variable = parameter_by_ref
: > : return_value = Bar(local_variable)
: > : Foo = local_variable
: > : End Function
: > :
: > : Function Bar(parameter_by_ref)
: > : parameter_by_ref = parameter_by_ref + 1
: > : Bar = "Hello World"
: > : End Function
: > :
: > : Response.Write Foo(4)
: > : %>
: >
: > Also helpful... thanks.
: >
: > This was very interesting to see:
: >
: > Option Explicit
: > Function Foo(parameter_by_ref)
: > Dim return_value, local_variable
: > local_variable = parameter_by_ref
: > Bar(local_variable)
: > Foo = local_variable
: > End Function
: >
: > sub Bar(parameter_by_ref)
: > parameter_by_ref = parameter_by_ref + 1
: > End sub
: >
: > wscript.echo Foo(4)
: >
: > Result: 4
: >
: > Option Explicit
: > Function Foo(parameter_by_ref)
: > Dim return_value, local_variable
: > local_variable = parameter_by_ref
: > Bar local_variable
: > Foo = local_variable
: > End Function
: >
: > sub Bar(parameter_by_ref)
: > parameter_by_ref = parameter_by_ref + 1
: > End sub
: >
: > wscript.echo Foo(4)
: >
: > Result: 5
:
: In your first example, this line:
:
: Bar(local_variable)
:
: is interpreted by the parser as passing the expression "(local_variable)"
to
: the Bar procedure. The parenthesis in this case causes the parser to
: interpret the argument being passed to the Bar procedure as a complex
: expression instead of a simple variable reference. As such, what's being
: passed in this case is a reference to the implicit/pseudo variable used to
: hold the result of evaluating the "(local_variable)" expression. It would
be
: akin to this call:
:
: Bar local_variable + 1
:
: Or this one:
:
: Bar (local_variable + 1)
:
: Or this one:
:
: Bar 22/7
:
: You get the idea.

Ya, I got it. I just never knew the ( ) were such an issue.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp