[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keyword precedence

Craig Markwardt wrote:
> "Mark Hadfield" <m.hadfield@niwa.cri.nz> writes:
> > It's interesting that David Fanning and Martin Shultz have both recommended
> > the following idiom for establishing overridable defaults
> >
> > pro my_plot, COLOR=color, _EXTRA=extra
> >     if n_elements(color) eq 0 then color = 12
> >     plot, COLOR=12, _EXTRA=extra
> ****       Ooops  ^^     ****
> > end
> >
> > This has the effect, unintended and normally irrelevant, that if the
> > following call is made with the COLOR keyword set to an undefined variable
> >
> > my_plot, COLOR=color
> >
> > then this variable is set to 12 on output. It isn't too hard to imagine a
> > situation (successive calls to different routines with different default
> > colours) where this will bite an unwary programmer, though in several years
> > of using this idiom I have seldom thought about this side-effect and have
> > very seldom been bitten.
> I have had a difficult time keeping up with this thread.  Whew!  I
> often do my keyword passing with the following draconian but safe
> technique.
> pro my_plot, COLOR=color0, _EXTRA=extra
>     if n_elements(color0) eq 0 then color = 12 $
>     else color = floor(color0(0))
>     plot, COLOR=color, _EXTRA=extra
> end
> COLOR0 is the value passed in, which is distinct from the value of the
> local variable COLOR.  I agree. It's ugly.
> Craig
> --
> --------------------------------------------------------------------------
> Craig B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
> Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
> --------------------------------------------------------------------------

No, it's not ugly, it's utmost correct ;-) This is what I do
whenever I get caught by the situation that Mark points out -
once I discover that my return value is changed *and* that this
leads to undesired consequences (which most often it does not,
rather the opposite), then I change color to color0 or whatever.
To give you an example, where I rely on setting the keyword value
if it is undefined:

pro whatever, filename

    read_data, filename, data
    if n_elements(data) eq 0 then return
    print, ' Read data from file '+filename

Here, read_data will receive an undefined value if you pass no
filename to whatever. It then sets filename to a default search
pattern (e.g. '*.nc') and calls the dialog_pickfile to select a
file. The name of the file that is selected is stored in filename
for future reference (in this example, the print statement).
Alternatively, if you pass a fully qualified filename, the file
is opened with no further questions, or if you know a little more
about the file, you can pass a search mask like
'/home/myself/data/global*.nc' that will be used as filter for
dialog_pickfile. I find that this works very nicely and veeeery
conveniently in 99% of all cases - just occasionally if I want to
loop over several files at once and have them all "hand-picked",
then I will have to re-initialize filename each time.


[[ Dr. Martin Schultz   Max-Planck-Institut fuer Meteorologie   
[[                      Bundesstr. 55, 20146 Hamburg            
[[                      phone: +49 40 41173-308                 
[[                      fax:   +49 40 41173-298                 
[[ martin.schultz@dkrz.de