[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefined keyword variables
J.D. Smith (firstname.lastname@example.org) writes the kind of
article I wish I could write more often when he says:
> It's really not a difference between built-in and compiled routines,
> just well-written and poorly written routines. Back when I first
> noticed this phenomenon of built-in routines recognizing undefined
> variables, I immediately knew that RSI programmers had access to some
> argument functionality we in compiled-land did not. Thus was
> arg_present() born. I can now write a compiled routine which can:
> 1) Discern if a keyword is passed at all.
> 2) Discern if a keyword is passed with a value.
> 3) Discern if a keyword is passed which has scope in the passing level
> (by reference).
> Both 2 & 3 can be simultaneously true. So, since the introduction of
> arg_present, we can make programs which handle undefined submitted
> keywords gracefully, in whatever way necessary. This doesn't mean we
> *will*. Here is an example which demonstrates the various
> possibilities. Note that keyword_set is a really a subset of
> n_elements, and so isn't explicity included, though it can be useful.
> I can easily produce a routine which fails on some keywords and not on
> others when passed undefined variables. So can RSI. The problem is
> there isn't always a correct thing to do... maybe an error is actually
> appropriate in some cases, but consistency should be policy.
Good stuff, here.
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: email@example.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155