Use of "Optional" parameters in a Sub/Function?

[(Pete Cresswell)]

I've dabbled in "Optional" over the last few days and think I'm coming down
against using it.

Seems to me like it makes the code harder to read and more complicated.

Instead of using Optional, I'm making the parm a Variant and passing Null when
it's not used.... then checking for "If Len(theParmValu e & "") > 0... to see if
it is present.

That way I can eliminate checks for IsMissing(thePa rmValue)...
Anybody else have thoughts on this?
--
PeteCresswell

[Douglas J. Steele]

Sorry, but I fail to see how If Len(theParmValu e & "") > 0 is any easier to
read than If IsMissing(thePa rmValue).

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)

"(Pete Cresswell)" <x@y.z> wrote in message
news:td******** *************** *********@4ax.c om...

I've dabbled in "Optional" over the last few days and think I'm coming down against using it.

Seems to me like it makes the code harder to read and more complicated.

Instead of using Optional, I'm making the parm a Variant and passing Null when it's not used.... then checking for "If Len(theParmValu e & "") > 0... to see if it is present.

That way I can eliminate checks for IsMissing(thePa rmValue)...
Anybody else have thoughts on this?
--
PeteCresswell

[David W. Fenton]

Chuck Grimsby <c.*******@worl dnet.att.net.in valid> wrote in
news:t7******** *************** *********@4ax.c om:

Use the Optional keyword with a = "setting" if there isn't a
input. For example:

Public Function GetASetting( _
SettingToGet As String, _
Optional TableName As String = "USYS_tblSettin gs", _
Optional whatDB As DAO.Database = Nothing) _
As Variant

If whatever calls this function doesn't supply a TableName,
"USYS_tblSettin gs" is used by default.

Saves all that nasty checking for IsMissing... You do still have
to check for invalid stuff passed to your function or sub however!

I've often added optional arguments to version 2 of a commonly-used
function/sub. In that case, it's pretty important to use it, as
otherwise, existing code will break.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Eric Schittlipz]

"(Pete Cresswell)" <x@y.z> wrote in message
news:td******** *************** *********@4ax.c om...

I've dabbled in "Optional" over the last few days and think I'm coming
down
against using it.

Seems to me like it makes the code harder to read and more complicated.

Instead of using Optional, I'm making the parm a Variant and passing Null
when
it's not used.... then checking for "If Len(theParmValu e & "") > 0... to
see if
it is present.

That way I can eliminate checks for IsMissing(thePa rmValue)...
Anybody else have thoughts on this?
--
PeteCresswell

If there were no such thing as optional parameters, think how different your
coding would look. Some of the things you could no longer write would
include:
DoCmd.Close (You now write DoCmd.Close Null, Null, Null)
DoCmd.OpenForm "frmWhateve r" (You now write DoCmd.OpenForm "frmWhateve r",
Null, Null, Null, Null, Null, Null)
OK, these are methods of built-in objects, not your custom functions, but
doesn't the same principal apply? I don't see how forcing users of your
functions (yourself?) to always provide every parameter would increase
readability or fail to irritate. Perhaps, though, you are thinking of a
specific function and whether parameters should be optional in that
particular case.

[david epsom dot com dot au]

The "Optional Parameter" is a hang-over from the way a couple
of dudes implemented their macro-assembler on a PDP mini-computer
decades ago. It is indeed a nifty feature, even if it did
fall out of a historical accident, but it is incompatible with
most current ideas about computer language design (Pearl excepted:
the designer of Perl is strongly supportive of irregular forms
for common verbs like DoCmd.OpenForm) .

Ironic isn't it, that VB got optional parameters by aping C,
but C++ and OLE don't really have optional parameters any more?

In Access, optional parameters should default to Null, not
Missing (think about it!), but the fact is that Null is not
and cannot be a defined concept: we often wish Null to map
to 0 and "" and Empty and Error and Missing, and we often
wish Null to /NOT/ map to 0 or "" or Empty or Error or Missing:

there is no universal answer to some questions.

(david)
"(Pete Cresswell)" <x@y.z> wrote in message
news:td******** *************** *********@4ax.c om...

I've dabbled in "Optional" over the last few days and think I'm coming down against using it.

Seems to me like it makes the code harder to read and more complicated.

Instead of using Optional, I'm making the parm a Variant and passing Null when it's not used.... then checking for "If Len(theParmValu e & "") > 0... to see if it is present.

That way I can eliminate checks for IsMissing(thePa rmValue)...
Anybody else have thoughts on this?
--
PeteCresswell

[Trevor Best]

(Pete Cresswell) wrote:

I've dabbled in "Optional" over the last few days and think I'm coming down
against using it.

Seems to me like it makes the code harder to read and more complicated.

Instead of using Optional, I'm making the parm a Variant and passing Null when
it's not used.... then checking for "If Len(theParmValu e & "") > 0... to see if
it is present.

That way I can eliminate checks for IsMissing(thePa rmValue)...
Anybody else have thoughts on this?

I think it's (optional) useful and allows a default value to be passed
in rather than the usual nulls, zeros, zero length strings, etc.

--
This sig left intentionally blank