Re: Yet again, The Sky is Falling! [message #52966 is a reply to message #52872] |
Fri, 09 March 2007 11:43   |
Paul Van Delst[1]
Messages: 1157 Registered: April 2002
|
Senior Member |
|
|
mgalloy@gmail.com wrote:
> On Mar 9, 11:36 am, David Fanning <n...@dfanning.com> wrote:
>> Paul van Delst writes:
>>> But, then it's not an input parameter. It's an output.
>> It generally has to get into the program somehow. :-)
>>
>>> I'm f95-centric, and I know it doesn't apply completely to IDL for a number of reasons,
>>> but I don't think people should new code where the functionality depends on *how* the
>>> arguments are passed (i.e. by value or reference).
>> I'm not saying "pass by reference" is not dangerous, it is,
>> but it is no more dangerous, it seems to me, than a dynamically
>> (and weakly) typed language. Goodness, one of the reasons I LIKE
>> IDL is because you can do all these weird things that would
>> get your knickers in a snit in some other language.
>>
>> Sure, you have to learn a few rules, and usually you learn
>> them the hard way, but you only have to learn them three or
>> four times before they get cemented in your brain. I think
>> it is a small price to pay for a LOT of power.
>
> I agree that pass by reference can be dangerous and very useful. To
> clarify my "moral":
>
> 1. Document clearly which parameters are input, which are output, and
> which are both (i.e. modifying a variable "in place"). Don't change
> the input ones! If you need to have a default value for that input in
> the routine, create a new local variable.
You said it better than I did. What you said above is what I meant.
> 2. Don't pass the same named variable as both an input and output
> parameter in a routine call. (Or as two output parameters!)
Good lord. Why would anyone do *that*? (In any language) :o)
cheers,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
|
|
|