Functions vs. subs and role reversal

[Colin Mc Mahon]

Hi all,

First off I know the difference between functions and subs, basically a
function returns a value on execution of a code block wheras a sub just
executes a code block (more or less).

I have found however that if I 'call' a function in the same way as I would
a sub the function executes the code as if it were a sub ie:

Call openDB 'this is a function which creates a connection object to
my database called dbConn which is the available to the rest of my code.

openDB is most definitely a function and this method of calling it works
perfectly well.

My questions are thus:
1) Am I just ignorant of calling procedures?
2) Is it a good idea to call functions like this, or should a sub be a sub
and a function be a function?
3) If not a good idea then why not?

Any links or thoughts on this 'problem' would be highly appreciated.

Colin Mc mahon

 

[Ken Schaefer]

You should use a function when you need to return a value from the function.

eg:

<%
myInt = AddSomeNumbers(2,3)

Function AddSomeNumbers( _
ByVal intFirstNumber, _
ByVal intSecondNumber _
)

AddSomeNumbers = intFirstNumber + intSecondNumber

End Function
%>

In your case, it appears that your function does some work on a globally
scoped variable. I would not recommend that. Instead, use a Sub -or- do
something like:

<%
' Set objConn to reference what is returned by the function
Set objConn = OpenDBConn(myConnString)
%>

or in a sub:

<%
Dim objConn

Sub OpenDBConn

' Here we are working with a *globally* scoped variable
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open myDBConnString

End Sub
%>

Cheers
Ken

: Hi all,
:
: First off I know the difference between functions and subs, basically a
: function returns a value on execution of a code block wheras a sub just
: executes a code block (more or less).
:
: I have found however that if I 'call' a function in the same way as I
would
: a sub the function executes the code as if it were a sub ie:
:
: Call openDB 'this is a function which creates a connection object
to
: my database called dbConn which is the available to the rest of my code.
:
: openDB is most definitely a function and this method of calling it works
: perfectly well.
:
: My questions are thus:
: 1) Am I just ignorant of calling procedures?
: 2) Is it a good idea to call functions like this, or should a sub be a sub
: and a function be a function?
: 3) If not a good idea then why not?
:
: Any links or thoughts on this 'problem' would be highly appreciated.
:
: Colin Mc mahon
:
:

 

[Atrax]

Well, I can't see how it could harm to do this - though 'best practice'
would logically say use subs for non-return and functions for return.

with this trick I guess you can have a function which plays both
roles....

like I said, can't see how it could harm...





________________________________________
Atrax. MVP, IIS
http://rtfm.atrax.co.uk/

newsflash : Atrax.Richedit 1.0 now released.
http://rtfm.atrax.co.uk/infinitemonkeys/components/Atrax.RichEdit/

 

[Dan Brussee]

Hi all,

First off I know the difference between functions and subs, basically a
function returns a value on execution of a code block wheras a sub just
executes a code block (more or less).

I have found however that if I 'call' a function in the same way as I would
a sub the function executes the code as if it were a sub ie:

Call openDB 'this is a function which creates a connection object to
my database called dbConn which is the available to the rest of my code.

openDB is most definitely a function and this method of calling it works
perfectly well.

My questions are thus:
1) Am I just ignorant of calling procedures?
2) Is it a good idea to call functions like this, or should a sub be a sub
and a function be a function?
3) If not a good idea then why not?

Any links or thoughts on this 'problem' would be highly appreciated.

No real difference. Personal style. To blur the lines even more, the
Call keyword is actually optional.

dim x, y
function fn ()
x = "foo"
fn = x
end function


x = "bar"
y = fn() ' y is now "foo" along with x.

x = "bar"
y = "bar" ' back to scratch
call fn() ' x is now "foo", but y is still "bar"

x = "bar"
y = "bar" ' back again
fn ' notice now parens. Same result as previous example.

 

[Chris Barber]

It's mostly a conceptual difference (although there is a diff in the code
and execution times - I think - based on the explicit declaration for a sub
that no return value is required to be processed ... I'm pretty sure Michael
Harris wrote something about it a few weeks back).

A function should return something based on what was passed in but should
not modify anything else such as global variables.
A sub should do some work and may decide to access / modify global variables
etc.
It's also good to get into the habit of not changing or using the passed in
parameters as returning variables.

Other than these 'design' thoughts it's pretty much arbitrary what you do.
I have to admit that I did have a short period where I was doing nothing but
functions with boolean return types (as replacement for a sub) so that I
could tack on error handling after the fact. I never did add error handling
to that level and just spent 2 hours making them all subs again! This was
before I knew about cascading error raise and handling so please don't start
on about how to do 'real' error handling.

Chris.

Hi all,

First off I know the difference between functions and subs, basically a
function returns a value on execution of a code block wheras a sub just
executes a code block (more or less).

I have found however that if I 'call' a function in the same way as I would
a sub the function executes the code as if it were a sub ie:

Call openDB 'this is a function which creates a connection object to
my database called dbConn which is the available to the rest of my code.

openDB is most definitely a function and this method of calling it works
perfectly well.

My questions are thus:
1) Am I just ignorant of calling procedures?
2) Is it a good idea to call functions like this, or should a sub be a sub
and a function be a function?
3) If not a good idea then why not?

Any links or thoughts on this 'problem' would be highly appreciated.

Colin Mc mahon