comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Optional parameters
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Optional parameters [message #38194 is a reply to message #38192] Tue, 24 February 2004 09:59 Go to previous messageGo to previous message
Pavel Romashkin is currently offline  Pavel Romashkin
Messages: 166
Registered: April 1999
Senior Member
I agree. I never had a problem with this because I never put unneeded
variables in a call to a procedure. I fail to see the logic in putting

myfunction, var1=uselessvar

as opposed to just

myfunction

and then worrying about uselessvar getting defined all of a sudden. The
only time this might happen in real life I suppose is if you use
copy-paste to insert function calls that address all of the provided keywords.
Pavel

David Fanning wrote:
>
> David Fanning writes:
>
>> Here is the same program with an optional keyword parameter
>> named "junk":
>>
>> PRO TEST, JUNK=junk
>> On_Error, 1
>> IF N_Elements(junk) EQ 0 THEN junk = 3
>> Print, junk
>> END
>
> An alert reader, who wishes to remain anonymous, but who
> is well-known in the IDL programming community, points out
> that there is one possible gotcha in this formulation.
> Namely, that an input variable that was previously undefined
> is now defined by my example. In other words:
>
> IDL> Help, junk
> JUNK UNDEFINED = <Undefined>
> IDL> Test, JUNK=junk
> IDL> Help, junk
> JUNK INT = 3
>
> If the user were counting on the variable junk to remain
> undefined for some reason, there would be a nasty surprise
> in store here.
>
> This is, of course, a consequence of parameters being input
> or output (or both) according to usage. I guess strictly
> speaking, you would need two different variables to represent
> parameters that are strictly input variables. The reader suggests
> this:
>
> PRO TEST, JUNK=junk_local
> On_Error, 1
> junk = n_elements(junk_local) eq 0 ? 3 : junk_local
> Print, junk
> END
>
> While I absolutely agree with the logic, I find this to be a royal
> pain in the neck in practice. Do you read Whinnie the Pooh? I am
> one of those "bears of little brain" and having two names for the
> same variable sends me into fits of confusion every time. Lord knows
> I have enough problems just keeping up with defining the same keywords
> over and over again for INIT, SetProperty, and GetProperty methods.
> Double names sounds like double work to me. I guess I'd rather track
> down the very rare "defined when I didn't want it to be" error than
> be frustrated with all the damn typos! :-)
>
> Cheers,
>
> David
>
> P.S. Let's just say I admire the good folks at RSI who are going
> to all the trouble to make input keywords strictly input. :-)
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: pointer and structure stuff ...
Next Topic: Re: Something similar to a "Widget_Container" ?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 19:00:35 PDT 2025

Total time taken to generate the page: 0.48029 seconds