Re: translating an array name to a string

[Craig Markwardt <craigmnet(at)cow.physics.wisc.edu>]

"J.D. Smith" <jdsmith@astro.cornell.edu> writes:
> This is definitely nicer looking, and it reminded me of a caveat.  If
> you attempt to fetch a variable which doesn't yet exist, an undefined
> variable will be created on that level for you.


For versions of IDL 5.3 and greater. :-) I should document this.

> I think our methods offer equal protection against certain types of
> failure, but I also think call_function provides additional insurance
> against RSI deciding specifically to remove our capacity to use
> routine_names() (which they might do if we keep talking about it so much
> and people catch on!).  It is simple to parse *compiler* statements like
> forward_function for disallowed names.  It is impossible (OK, very, very
> awkward), to prohibit the use of classified *strings*.  This is probably
> paranoid, but that's why I chose call_function.  

Yikes! Paranoid indeed.

This is one argument in favor of an open version of IDL, so language
sabotage like this wouldn't be possible.

Craig

-- 
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
--------------------------------------------------------------------------