[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefined keyword variables
- Subject: Re: undefined keyword variables
- From: davidf(at)dfanning.com (David Fanning)
- Date: Sat, 30 Oct 1999 20:39:02 -0600
- Newsgroups: comp.lang.idl-pvwave
- Organization: Fanning Software Consulting
- References: <firstname.lastname@example.org>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:17013
Mark Fardal (email@example.com) writes:
> A question: should you always be able to pass undefined variables as
> keywords to IDL routines?
Surely this is a rhetorical question. Alright, then. Yes,
absolutely. But, of course, not all of our programs are this
well written, alas.
> For example, PLOT is smart enough not to do anything with this undefined
> IDL> plot,x,y,title=donkeykong
> [plots fine]
> but not this one
> IDL> plot,x,y,clip=pong
> % PLOT: Variable is undefined: PONG.
> % Execution halted at: $MAIN$
> [no plot produced]
> IDL> help,donkeykong, pong
> DONKEYKONG UNDEFINED = <Undefined>
> PONG UNDEFINED = <Undefined>
> Should this be considered a bug in plot, or as normal behavior?
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
> But if you
> can't, it leads to annoying problems in writing interfaces to any
> routine with lots of keywords. In my case, I wanted to write a
> routine that called plot and then oplot, which use different sets of
> optional keyword parameters. The best solution I know of is to
> construct a value for the _extra keyword, but it's a pretty convoluted
In what sense do you mean convoluted?
PRO JUNK, data, moredata, _Extra=extra
IF N_Elements(data) EQ 0 THEN data = [3,2,5]
IF N_Elements(moredata) EQ 0 THEN moredata = [1,2,1]
PLOT, data, _Extra=extra
OPLOT, moredata, _Extra=extra
That doesn't seem very convoluted to me. Any keyword in the
extra structure that is not appropriate for the command it
is passed to is simply ignored.
The only potential problem I see is that if you wanted to
overplot in a particular color. Setting Color=200 would
set the color for *both* data lines. The only solution
would be to define a specific OCOLOR keyword for the JUNK
procedure, so that the overplot color could be set independently
of the plot color.
But that sure beats defining and checking all 60 possible
keywords that we might want to use.
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: firstname.lastname@example.org
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155