| Re: undefined keyword variables [message #17611 is a reply to message #17531] |
Mon, 01 November 1999 00:00   |
J.D. Smith
Messages: 214
Registered: August 1996
|
Senior Member |
|
|
Craig Markwardt wrote:
>
> davidf@dfanning.com (David Fanning) writes:
>>
>> Mark Fardal (fardal@weka.astro.umass.edu) writes:
>>
>>> A question: should you always be able to pass undefined variables as
>>> keywords to IDL routines?
>>
>> Oh, this is absolutely normal behavior. (At least under the
>> usual standards by which such things are judged in IDL.)
>> Is it *correct* behavior? Don't know. But I would doubt it.
>> Seems to me *any* optional input keyword should be capable of
>> accepting an undefined variable as an argument. I would run
>> it by RSI for confirmation.
>>
>>> In general I don't know why you should be able to safely feed
>>> undefined variables to routines and expect them to work.
>>
>> Well, because you expect decent programmers to test any
>> variable they expect to receive and define default values
>> if one is not passed in. (As well as testing for data type
>> and structure, but who among us does this except under
>> exceptional conditions?)
>
> I am never sure any more how undefined keywords are passed. It seems
> to make a difference whether it's a built-in routine, or an IDL
> routine. It seems to make a difference whether it's IDL 4 or 5. It
> seems to make a difference if you refer to the variable by name before
> calling the procedure (not necessarily setting its value). All these
> factors make it hard to handle pass-through keywords consistently. It
> would be nice (no, crucial!) to have this more carefully documented by
> RSI.
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.
pro testkey,KEY1=k1
case arg_present(k1)+2L*(n_elements(k1) ne 0) of
0: print,'Nothing was passed through the keyword.'
1: print,'An undefined variable was passed.'
2: print,'A value without scope in the passing level was passed.'
3: print,'A defined and valued variable was passed.'
endcase
end
IDL> testkey
Nothing was passed through the keyword.
IDL> testkey,KEY1=1
A value without scope in the passing level was passed.
IDL> testkey,KEY1=undef_var
An undefined variable was passed.
IDL> undef_var=[1,2,3]
IDL> testkey,KEY1=undef_var
A defined and valued variable was passed.
RSI programmers have similar (and perhaps more) functionality for
writing built-in programs. This doesn't mean they'll use it
consistently or correctly.
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.
JD
--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
