Re: Static Variables in a subprocedure

Barbara Morris wrote:

Joe Pluta wrote:

... But if you're not, then changing the number of parms is as good a way to communicate as any. If you normally DO pass parameters, then DON'T pass any to signal a initialization. If you normally DON'T pass any parameters, then DO pass one to signal initialization.

A problem with this technique is that you have to make all the parameters *NOPASS. There's a way to get around it: Create a second prototype for the procedure with the same EXTPROC, but no parameters; call it something like myproc_reset. Then when you want the procedure to reset itself, call myproc_reset() instead of myproc(parms).

I'm of at least two minds about the relative goodness of the two techniques, but the "lying to the compiler" aspect of having two prototypes for a procedure seems less likely to cause maintenance problems that having all the parameters for the normal call be options(*nopass).

Oh my, Barbara, leave it to you to bring a really clever solution to the table. And I use clever with all the connotations; it's not only a very slick way to get around the problem of having *NOPASS for everything, at the same time the "lying to the compiler" concept gives me a tiny bit of the heebie jeebies.

In this case, though, it might not be really lying. Adding a bunch of *NOPASS to the prototype is actually the bigger lie, isn't it? Not to mention that it removes some error checking. And the chance that you would somehow change one prototype to point to a new procedure and not the other seems pretty remote.

Hmmm... I think I'd go with the multiple prototypes on this one, although it's a close call.

Joe (jotting down a new entry in his Cool Things Learned From Barbara book)