Re: Static Variables in a subprocedure

[Adam Glauser <adamglauser@xxxxxxxxxxxx>]

Ken, I hope you don't mind if I jump in here too.  The way I look at it, 
properly encapsulating the variable in question trumps any argument 
about the weirdness of using a second prototype.

For one thing, you don't really _need_ the second prototype.  You could, 
as was already suggested, use *NOPASS or *OMIT for all the parameters. 
Of course that method has its own pitfalls, and personally I prefer 
Barbara's method because it is more self-documenting.

Also, you say:
> All global variables subject to being "messed with".  Even static
> local variables are subject to being "messed with" inside of the
> procedure.
>
> Competent programmers pay attention to what they are doing, so I don't
> consider protection from being messed with as a reason for lying to
> the compiler to allow a single procedure to have two different
> prototypes.

You can mess with just about anything if you really put your mind to it. 
Properly encapsulating as a local variable just makes it harder.  Of 
even more benefit, in my opinion, proper encapsulation means that the 
competent programmer needs keep one less thing in mind when working on 
unrelated procedures within the module.